Use TaskScheduler instead of WorkerPool in page_handler.cc.

Use TaskScheduler instead of WorkerPool in page_handler.cc.

The following traits are used:

Priority: Inherited (default)
  The priority is inherited from the calling context (i.e. TaskTraits
  are initialized with the priority of the current task).

Shutdown behavior: CONTINUE_ON_SHUTDOWN
  Tasks posted with this mode which have not started executing before
  shutdown is initiated will never run. Tasks with this mode running at
  shutdown will be ignored (the worker will not be joined).

  Note: Tasks that were previously posted to base::WorkerPool should
  use this shutdown behavior because this is how base::WorkerPool
  handles all its tasks.

Does Not Block (default):
  Tasks without the MayBlock() and WithBaseSyncPrimitives() traits
  may not block.

BUG=659191
Committed: https://crrev.com/375ad9dd131cbc748491195c7bb43bbcfefe76fa
Cr-Commit-Position: refs/heads/master@{#441180}

[fdoray, 2016-12-31 21:08:55]

The CQ bit was checked by fdoray@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-31 21:09:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-31 21:57:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-31 21:57:44]

Dry run: This issue passed the CQ dry run.

[fdoray, 2017-01-01 19:20:56]

fdoray@chromium.org changed reviewers:
+ dgozman@chromium.org

[fdoray, 2017-01-01 19:20:57]

PTAL. WorkerPool is being deprecated in favor of TaskScheduler.

[dgozman, 2017-01-02 04:48:41]

Is there a doc or a guide outlining new traits system?

From the new code it's not clear for me where does the task go, is it blocking
some important thread, or on which thread the objects I passed with ownership
will be destroyed.

[fdoray, 2017-01-02 16:55:16]

On 2017/01/02 04:48:41, dgozman wrote:
> Is there a doc or a guide outlining new traits system?
> 
> From the new code it's not clear for me where does the task go, is it blocking
> some important thread, or on which thread the objects I passed with ownership
> will be destroyed.

You can learn a lot about TaskScheduler by reading comments in
base/task_scheduler/post_task.h and base/task_scheduler/task_traits.h. You can
also read the full design doc :
https://docs.google.com/a/chromium.org/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrk...

Tl;Dr

TaskScheduler is a dynamic thread pool. It creates/destroys threads depending on
workload. All tasks are associated with traits. The WithPriority() trait
determines in which order tasks are scheduled. Tasks without an explicit
WithPriority() trait inherit their priority from the calling context
(USER_VISIBLE by default). See CL description for the WithShutdownBehavior()
trait. The MayBlock() trait is used on some platforms as an indicator that the
task is probably not using the CPU when it takes a lot of time to run (and hence
that new threads should be created to maximize CPU utilization). On other
platforms, CPU utilization of tasks is measured dynamically using OS APIs.

Since TaskScheduler creates/destroys threads on demand, your task cannot block
anything forever. Arguments are destroyed right after the task runs (on the same
thread). This is the same behavior as base::WorkerPool, to which the task was
posted before this CL.

[dgozman, 2017-01-03 18:02:47]

On 2017/01/02 16:55:16, fdoray wrote:
> On 2017/01/02 04:48:41, dgozman wrote:
> > Is there a doc or a guide outlining new traits system?
> > 
> > From the new code it's not clear for me where does the task go, is it
blocking
> > some important thread, or on which thread the objects I passed with
ownership
> > will be destroyed.
> 
> You can learn a lot about TaskScheduler by reading comments in
> base/task_scheduler/post_task.h and base/task_scheduler/task_traits.h. You can
> also read the full design doc :
>
https://docs.google.com/a/chromium.org/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrk...
> 
> Tl;Dr
> 
> TaskScheduler is a dynamic thread pool. It creates/destroys threads depending
on
> workload. All tasks are associated with traits. The WithPriority() trait
> determines in which order tasks are scheduled. Tasks without an explicit
> WithPriority() trait inherit their priority from the calling context
> (USER_VISIBLE by default). See CL description for the WithShutdownBehavior()
> trait. The MayBlock() trait is used on some platforms as an indicator that the
> task is probably not using the CPU when it takes a lot of time to run (and
hence
> that new threads should be created to maximize CPU utilization). On other
> platforms, CPU utilization of tasks is measured dynamically using OS APIs.
> 
> Since TaskScheduler creates/destroys threads on demand, your task cannot block
> anything forever. Arguments are destroyed right after the task runs (on the
same
> thread). This is the same behavior as base::WorkerPool, to which the task was
> posted before this CL.

Thanks for explanation. I think it would've been helpful to include that
information into the bug linked.
I'm probably not the only one who wants to know what's happening.

lgtm

[fdoray, 2017-01-03 18:06:00]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2017-01-03 18:06:15]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-03 19:18:39]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1483466760693660, "parent_rev":
"c76b60569271a5ebff80a87cf8df5352c838bd7e", "commit_rev":
"1c58bdccac6591e908999e9aa28040b4b58ec860"}

[commit-bot: I haz the power, 2017-01-03 19:19:08]

Description was changed from

==========
Use TaskScheduler instead of WorkerPool in page_handler.cc.

The following traits are used:

Priority: Inherited (default)
  The priority is inherited from the calling context (i.e. TaskTraits
  are initialized with the priority of the current task).

Shutdown behavior: CONTINUE_ON_SHUTDOWN
  Tasks posted with this mode which have not started executing before
  shutdown is initiated will never run. Tasks with this mode running at
  shutdown will be ignored (the worker will not be joined).

  Note: Tasks that were previously posted to base::WorkerPool should
  use this shutdown behavior because this is how base::WorkerPool
  handles all its tasks.

Does Not Block (default):
  Tasks without the MayBlock() and WithBaseSyncPrimitives() traits
  may not block.

BUG=659191
==========

to

==========
Use TaskScheduler instead of WorkerPool in page_handler.cc.

The following traits are used:

Priority: Inherited (default)
  The priority is inherited from the calling context (i.e. TaskTraits
  are initialized with the priority of the current task).

Shutdown behavior: CONTINUE_ON_SHUTDOWN
  Tasks posted with this mode which have not started executing before
  shutdown is initiated will never run. Tasks with this mode running at
  shutdown will be ignored (the worker will not be joined).

  Note: Tasks that were previously posted to base::WorkerPool should
  use this shutdown behavior because this is how base::WorkerPool
  handles all its tasks.

Does Not Block (default):
  Tasks without the MayBlock() and WithBaseSyncPrimitives() traits
  may not block.

BUG=659191

Review-Url: https://codereview.chromium.org/2608963002
==========

[commit-bot: I haz the power, 2017-01-03 19:19:09]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2017-01-03 19:22:29]

Description was changed from

==========
Use TaskScheduler instead of WorkerPool in page_handler.cc.

The following traits are used:

Priority: Inherited (default)
  The priority is inherited from the calling context (i.e. TaskTraits
  are initialized with the priority of the current task).

Shutdown behavior: CONTINUE_ON_SHUTDOWN
  Tasks posted with this mode which have not started executing before
  shutdown is initiated will never run. Tasks with this mode running at
  shutdown will be ignored (the worker will not be joined).

  Note: Tasks that were previously posted to base::WorkerPool should
  use this shutdown behavior because this is how base::WorkerPool
  handles all its tasks.

Does Not Block (default):
  Tasks without the MayBlock() and WithBaseSyncPrimitives() traits
  may not block.

BUG=659191

Review-Url: https://codereview.chromium.org/2608963002
==========

to

==========
Use TaskScheduler instead of WorkerPool in page_handler.cc.

The following traits are used:

Priority: Inherited (default)
  The priority is inherited from the calling context (i.e. TaskTraits
  are initialized with the priority of the current task).

Shutdown behavior: CONTINUE_ON_SHUTDOWN
  Tasks posted with this mode which have not started executing before
  shutdown is initiated will never run. Tasks with this mode running at
  shutdown will be ignored (the worker will not be joined).

  Note: Tasks that were previously posted to base::WorkerPool should
  use this shutdown behavior because this is how base::WorkerPool
  handles all its tasks.

Does Not Block (default):
  Tasks without the MayBlock() and WithBaseSyncPrimitives() traits
  may not block.

BUG=659191

Committed: https://crrev.com/375ad9dd131cbc748491195c7bb43bbcfefe76fa
Cr-Commit-Position: refs/heads/master@{#441180}
==========

[commit-bot: I haz the power, 2017-01-03 19:22:30]

Patchset 1 (id:??) landed as
https://crrev.com/375ad9dd131cbc748491195c7bb43bbcfefe76fa
Cr-Commit-Position: refs/heads/master@{#441180}

[fdoray, 2017-01-04 16:38:32]

On 2017/01/03 18:02:47, dgozman wrote:
> On 2017/01/02 16:55:16, fdoray wrote:
> > On 2017/01/02 04:48:41, dgozman wrote:
> > > Is there a doc or a guide outlining new traits system?
> > > 
> > > From the new code it's not clear for me where does the task go, is it
> blocking
> > > some important thread, or on which thread the objects I passed with
> ownership
> > > will be destroyed.
> > 
> > You can learn a lot about TaskScheduler by reading comments in
> > base/task_scheduler/post_task.h and base/task_scheduler/task_traits.h. You
can
> > also read the full design doc :
> >
>
https://docs.google.com/a/chromium.org/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrk...
> > 
> > Tl;Dr
> > 
> > TaskScheduler is a dynamic thread pool. It creates/destroys threads
depending
> on
> > workload. All tasks are associated with traits. The WithPriority() trait
> > determines in which order tasks are scheduled. Tasks without an explicit
> > WithPriority() trait inherit their priority from the calling context
> > (USER_VISIBLE by default). See CL description for the WithShutdownBehavior()
> > trait. The MayBlock() trait is used on some platforms as an indicator that
the
> > task is probably not using the CPU when it takes a lot of time to run (and
> hence
> > that new threads should be created to maximize CPU utilization). On other
> > platforms, CPU utilization of tasks is measured dynamically using OS APIs.
> > 
> > Since TaskScheduler creates/destroys threads on demand, your task cannot
block
> > anything forever. Arguments are destroyed right after the task runs (on the
> same
> > thread). This is the same behavior as base::WorkerPool, to which the task
was
> > posted before this CL.
> 
> Thanks for explanation. I think it would've been helpful to include that
> information into the bug linked.
> I'm probably not the only one who wants to know what's happening.
> 
> lgtm

I update the bug description with the information I provided you in this CL.