Use TaskScheduler instead of WorkerPool in fake_bluetooth_device_client.cc.

Use TaskScheduler instead of WorkerPool in fake_bluetooth_device_client.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.

May Block:
  Tasks posted with MayBlock() may block. This includes but is not
  limited to tasks that wait on synchronous file I/O operations:
  read or write a file from disk, interact with a pipe or a socket,
  rename or delete a file, enumerate files in a directory, etc. This
  trait isn't required for the mere use of locks.

BUG=659191
Review-Url: https://codereview.chromium.org/2606193002
Cr-Commit-Position: refs/heads/master@{#442891}
Committed: https://chromium.googlesource.com/chromium/src/+/8f8b27e9d0744d90601d0dbb87a73470a03b01f4

[fdoray, 2016-12-31 21:25:28]

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:25:34]

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:55:43]

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

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

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[fdoray, 2017-01-01 19:31:50]

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

[commit-bot: I haz the power, 2017-01-01 19:31:57]

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

[fdoray, 2017-01-01 20:04:02]

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

[commit-bot: I haz the power, 2017-01-01 20:04:06]

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, 2017-01-01 20:49:06]

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

[commit-bot: I haz the power, 2017-01-01 20:49:07]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[fdoray, 2017-01-10 14:15:39]

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

[commit-bot: I haz the power, 2017-01-10 14:15:56]

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, 2017-01-10 14:54:21]

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

[commit-bot: I haz the power, 2017-01-10 14:54:22]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[fdoray, 2017-01-10 15:23:22]

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

[commit-bot: I haz the power, 2017-01-10 15:23:43]

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, 2017-01-10 15:31:22]

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

[commit-bot: I haz the power, 2017-01-10 15:31:23]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[fdoray, 2017-01-10 15:58:44]

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

[commit-bot: I haz the power, 2017-01-10 15:59:14]

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, 2017-01-10 17:37:11]

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

[commit-bot: I haz the power, 2017-01-10 17:37:11]

Dry run: This issue passed the CQ dry run.

[fdoray, 2017-01-10 17:38:55]

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

[fdoray, 2017-01-10 17:38:57]

PTAL

[scheib, 2017-01-11 04:00:34]

LGTM, though this caused me to go read code comments for  MayBlock.

I suggest that comment be expanded further to be more specific about what
'locks' refers to in "This trait isn't required for the mere use of locks". Does
it mean lock primitives in src/base, or OS level locks, or what?

Why should MayBlock trait be used, when should it be avoided? What impact will
using it have? The current comment only partially answers this, explaining that
"tasks that wait on synchronous file I/O operations" will have it ... but what
is the impact of that?

[fdoray, 2017-01-11 13:44:39]

On 2017/01/11 04:00:34, scheib wrote:
> LGTM, though this caused me to go read code comments for  MayBlock.
> 
> I suggest that comment be expanded further to be more specific about what
> 'locks' refers to in "This trait isn't required for the mere use of locks".
Does
> it mean lock primitives in src/base, or OS level locks, or what?

Any lock. You must use MayBlock() if your task blocks on things other than locks
and methods covered by WithBaseSyncPrimitives().

> 
> Why should MayBlock trait be used, when should it be avoided? What impact will
> using it have? The current comment only partially answers this, explaining
that
> "tasks that wait on synchronous file I/O operations" will have it ... but what
> is the impact of that?

MayBlock() provides information about your task to TaskScheduler. We decided not
to document how TaskScheduler uses it in task_traits.h as this is an
implementation detail that may change [1]. There is no reason to avoid using
this trait, it just documents what your task does.

[1] When a MayBlock() task takes a long time to run, TaskScheduler considers
that it is off-CPU and starts scheduling tasks on a new thread until it
completes.

[fdoray, 2017-01-11 13:44:45]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2017-01-11 13:45:12]

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-11 13:49:14]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1484142285846780,
"parent_rev": "dee07d3fac1402155ac4a17245501b6096605b9f", "commit_rev":
"8f8b27e9d0744d90601d0dbb87a73470a03b01f4"}

[commit-bot: I haz the power, 2017-01-11 13:49:40]

Description was changed from

==========
Use TaskScheduler instead of WorkerPool in fake_bluetooth_device_client.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.

May Block:
  Tasks posted with MayBlock() may block. This includes but is not
  limited to tasks that wait on synchronous file I/O operations:
  read or write a file from disk, interact with a pipe or a socket,
  rename or delete a file, enumerate files in a directory, etc. This
  trait isn't required for the mere use of locks.

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

to

==========
Use TaskScheduler instead of WorkerPool in fake_bluetooth_device_client.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.

May Block:
  Tasks posted with MayBlock() may block. This includes but is not
  limited to tasks that wait on synchronous file I/O operations:
  read or write a file from disk, interact with a pipe or a socket,
  rename or delete a file, enumerate files in a directory, etc. This
  trait isn't required for the mere use of locks.

BUG=659191

Review-Url: https://codereview.chromium.org/2606193002
Cr-Commit-Position: refs/heads/master@{#442891}
Committed:
https://chromium.googlesource.com/chromium/src/+/8f8b27e9d0744d90601d0dbb87a7...
==========

[commit-bot: I haz the power, 2017-01-11 13:49:42]

Committed patchset #6 (id:100001) as
https://chromium.googlesource.com/chromium/src/+/8f8b27e9d0744d90601d0dbb87a7...

[scheib, 2017-01-11 18:46:02]

On 2017/01/11 13:44:39, fdoray wrote:
> On 2017/01/11 04:00:34, scheib wrote:
> > LGTM, though this caused me to go read code comments for  MayBlock.
> > 
> > I suggest that comment be expanded further to be more specific about what
> > 'locks' refers to in "This trait isn't required for the mere use of locks".
> Does
> > it mean lock primitives in src/base, or OS level locks, or what?
> 
> Any lock. You must use MayBlock() if your task blocks on things other than
locks
> and methods covered by WithBaseSyncPrimitives().
> 
> > 
> > Why should MayBlock trait be used, when should it be avoided? What impact
will
> > using it have? The current comment only partially answers this, explaining
> that
> > "tasks that wait on synchronous file I/O operations" will have it ... but
what
> > is the impact of that?
> 
> MayBlock() provides information about your task to TaskScheduler. We decided
not
> to document how TaskScheduler uses it in task_traits.h as this is an
> implementation detail that may change [1]. There is no reason to avoid using
> this trait, it just documents what your task does.
> 
> [1] When a MayBlock() task takes a long time to run, TaskScheduler considers
> that it is off-CPU and starts scheduling tasks on a new thread until it
> completes.

Thanks. I suggest adding a bit more to those comments -- even if not the
implementation impact, because it's still a bit not clear. Your write up here
helped me understand.