Use TaskScheduler instead of WorkerPool in platform_keys_nss.cc.

Use TaskScheduler instead of WorkerPool in platform_keys_nss.cc.

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

BUG=659191
Committed: https://crrev.com/1ed46e5a16b6f0ce4ee88eb1a7fd1a05383261ec
Cr-Commit-Position: refs/heads/master@{#435100}

[fdoray, 2016-11-24 20:22:54]

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

[commit-bot: I haz the power, 2016-11-24 20:23:18]

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-11-24 20:35:54]

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

[commit-bot: I haz the power, 2016-11-24 20:35:55]

Dry run: Try jobs failed on following builders:
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)

[fdoray, 2016-11-24 20:37:39]

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

[commit-bot: I haz the power, 2016-11-24 20:37:51]

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-11-24 21:34:26]

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

[commit-bot: I haz the power, 2016-11-24 21:34:27]

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

[fdoray, 2016-11-25 15:44:54]

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

[fdoray, 2016-11-25 15:44:55]

PTAL

[fdoray, 2016-11-25 16:39:39]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits() call. The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

Shutdown behavior: SKIP_ON_SHUTDOWN (default)
  Tasks posted with this mode that have not started executing at
  shutdown will never run. However, any task that has already begun
  executing when shutdown is invoked will be allowed to continue and
  will block shutdown until completion.

No File IO (default):
  The task does not perform synchronous IO operations.
  It spends most of its time using the CPU.

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

Shutdown behavior: SKIP_ON_SHUTDOWN (default)
  Tasks posted with this mode that have not started executing at
  shutdown will never run. However, any task that has already begun
  executing when shutdown is invoked will be allowed to continue and
  will block shutdown until completion.

No File IO (default):
  The task does not perform synchronous IO operations.
  It spends most of its time using the CPU.

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

[gab, 2016-11-28 16:28:18]

lgtm though check with OWNERS if this results in a TaskPriority::USER_VISIBLE
worthy outcome.

[gab, 2016-11-28 16:37:36]

On 2016/11/28 16:28:18, gab wrote:
> lgtm though check with OWNERS if this results in a TaskPriority::USER_VISIBLE
> worthy outcome.

Actually all WorkerPool threads had CONTINUE_ON_SHUTDOWN semantics before,
should keep this behavior.

[fdoray, 2016-11-28 22:06:13]

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

[commit-bot: I haz the power, 2016-11-28 22:07:09]

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-11-29 00:16:24]

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

[commit-bot: I haz the power, 2016-11-29 00:16:24]

Dry run: This issue passed the CQ dry run.

[fdoray, 2016-11-29 16:32:54]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

Shutdown behavior: SKIP_ON_SHUTDOWN (default)
  Tasks posted with this mode that have not started executing at
  shutdown will never run. However, any task that has already begun
  executing when shutdown is invoked will be allowed to continue and
  will block shutdown until completion.

No File IO (default):
  The task does not perform synchronous IO operations.
  It spends most of its time using the CPU.

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

[fdoray, 2016-11-29 16:36:28]

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

[fdoray, 2016-11-29 16:36:28]

Please review this CL. You should verify that the traits mentioned in the CL
description make sense for this task. Thanks!

Why are you doing this? WorkerPool is being deprecated in favor of
TaskScheduler. Read the design doc
https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa...

Is a BACKGROUND priority correct? See all priorities in
base/task_scheduler/task_traits.h. Tell us if this task should be USER_VISIBLE
or USER_BLOCKING.

Is a CONTINUE_ON_SHUTDOWN shutdown behavior correct? It should, because it's how
the task was handled by base::WorkerPool before this CL.

Is no file IO / no wait correct? Yes if the task is always ready to run on the
CPU (except page faults and locks). Tell us if that's not the case.

[emaxx, 2016-11-29 18:49:13]

Answering inline:


On 2016/11/29 16:36:28, fdoray wrote:
> Is a BACKGROUND priority correct? See all priorities in
> base/task_scheduler/task_traits.h. Tell us if this task should be USER_VISIBLE
> or USER_BLOCKING.

This code is used by the chrome.[enterprise.]platformKeys extensions API
implementation, and is triggered by the API calls performed by extensions.
So BACKGROUND seems to be the correct priority.


> Is a CONTINUE_ON_SHUTDOWN shutdown behavior correct? It should, because it's
how
> the task was handled by base::WorkerPool before this CL.

This seems to be fine, as the jobs use only methods of the net::X509Certificate
class and functions of the NSS library.


> Is no file IO / no wait correct? Yes if the task is always ready to run on the
> CPU (except page faults and locks). Tell us if that's not the case.

I'm pretty sure that all three functions actually DO IO and synchronous
waiting, as they perform crypto operations by talking to device's TPM
(trusted platform module).


Thinking out loud: in theory, however, changing the pool selection for these
tasks may break some preconditions in the existing neighbor code. I'm not
completely sure as I have basically inherited this code from an engineer who
is not working on Chrome anymore. But looking at the code now, I don't see
any obvious problems with changing the pool used for these asynchronous
tasks.

[fdoray, 2016-11-29 20:02:07]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait (default):
  The task waits on things other than file IO.

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

[fdoray, 2016-11-29 20:02:16]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait (default):
  The task waits on things other than file IO.

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait:
  The task waits on things other than file IO.

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

[fdoray, 2016-11-29 20:10:06]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

No File IO (default):
  The task does not perform synchronous IO operations.

No Wait:
  The task waits on things other than file IO.

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

[fdoray, 2016-11-29 20:17:10]

On 2016/11/29 18:49:13, emaxx wrote:
> Answering inline:
> 
> 
> On 2016/11/29 16:36:28, fdoray wrote:
> > Is a BACKGROUND priority correct? See all priorities in
> > base/task_scheduler/task_traits.h. Tell us if this task should be
USER_VISIBLE
> > or USER_BLOCKING.
> 
> This code is used by the chrome.[enterprise.]platformKeys extensions API
> implementation, and is triggered by the API calls performed by extensions.
> So BACKGROUND seems to be the correct priority.
> 
> 
> > Is a CONTINUE_ON_SHUTDOWN shutdown behavior correct? It should, because it's
> how
> > the task was handled by base::WorkerPool before this CL.
> 
> This seems to be fine, as the jobs use only methods of the
net::X509Certificate
> class and functions of the NSS library.
> 
> 
> > Is no file IO / no wait correct? Yes if the task is always ready to run on
the
> > CPU (except page faults and locks). Tell us if that's not the case.
> 
> I'm pretty sure that all three functions actually DO IO and synchronous
> waiting, as they perform crypto operations by talking to device's TPM
> (trusted platform module).

Indeed. Synchronous IO with the TPM requires WithFileIO().

> 
> 
> Thinking out loud: in theory, however, changing the pool selection for these
> tasks may break some preconditions in the existing neighbor code. I'm not
> completely sure as I have basically inherited this code from an engineer who
> is not working on Chrome anymore. But looking at the code now, I don't see
> any obvious problems with changing the pool used for these asynchronous
> tasks.

WorkerPool may run tasks it receives in parallel and in any order. Therefore,
these tasks should not depend on each other. Switching to TaskScheduler does not
break any guarantees provided by WorkerPool.

[fdoray, 2016-11-29 20:17:30]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

[emaxx, 2016-11-29 20:40:10]

Please see below my question regarding WithWait.
But LGTM anyway.


On 2016/11/29 20:17:10, fdoray wrote:
> Indeed. Synchronous IO with the TPM requires WithFileIO().

I'm wondering, isn't WithWait required too?
You know the differentiation between WithFileIO and WithWait better, but I
just wanted to point out the fact that between a crypto:: call and the actual
TPM there are many layers of indirection, including inter-process
communication. E.g. see this design doc (though it's probably somewhat
outdated):
https://sites.google.com/a/chromium.org/dev/developers/design-documents/chaps...


On 2016/11/29 20:17:10, fdoray wrote:
> On 2016/11/29 18:49:13, emaxx wrote:
> > Thinking out loud: in theory, however, changing the pool selection for these
> > tasks may break some preconditions in the existing neighbor code. I'm not
> > completely sure as I have basically inherited this code from an engineer who
> > is not working on Chrome anymore. But looking at the code now, I don't see
> > any obvious problems with changing the pool used for these asynchronous
> > tasks.
> 
> WorkerPool may run tasks it receives in parallel and in any order. Therefore,
> these tasks should not depend on each other. Switching to TaskScheduler does
not
> break any guarantees provided by WorkerPool.

Thanks for the clarification!

[fdoray, 2016-11-29 20:56:33]

On 2016/11/29 20:40:10, emaxx wrote:
> Please see below my question regarding WithWait.
> But LGTM anyway.
> 
> 
> On 2016/11/29 20:17:10, fdoray wrote:
> > Indeed. Synchronous IO with the TPM requires WithFileIO().
> 
> I'm wondering, isn't WithWait required too?
> You know the differentiation between WithFileIO and WithWait better, but I
> just wanted to point out the fact that between a crypto:: call and the actual
> TPM there are many layers of indirection, including inter-process
> communication. E.g. see this design doc (though it's probably somewhat
> outdated):
>
https://sites.google.com/a/chromium.org/dev/developers/design-documents/chaps...
> 
> 
> On 2016/11/29 20:17:10, fdoray wrote:
> > On 2016/11/29 18:49:13, emaxx wrote:
> > > Thinking out loud: in theory, however, changing the pool selection for
these
> > > tasks may break some preconditions in the existing neighbor code. I'm not
> > > completely sure as I have basically inherited this code from an engineer
who
> > > is not working on Chrome anymore. But looking at the code now, I don't see
> > > any obvious problems with changing the pool used for these asynchronous
> > > tasks.
> > 
> > WorkerPool may run tasks it receives in parallel and in any order.
Therefore,
> > these tasks should not depend on each other. Switching to TaskScheduler does
> not
> > break any guarantees provided by WorkerPool.
> 
> Thanks for the clarification!

Thanks for the review!

I added .WithWait(). Right now, WithWait() and WithFileIO() tasks are scheduled
the same way. In the future, we may decide to schedule them differently. We have
DCHECKs in place to make sure that tasks that do file I/O or wait via base/ APIs
have the right traits. If you do file I/O or wait without going through base/,
we trust you to use the right traits :)

[fdoray, 2016-11-29 20:56:39]

The CQ bit was checked by fdoray@chromium.org

[fdoray, 2016-11-29 20:56:39]

The patchset sent to the CQ was uploaded after l-g-t-m from gab@chromium.org,
emaxx@chromium.org
Link to the patchset: https://codereview.chromium.org/2526283004/#ps100001
(title: "add WithWait()")

[fdoray, 2016-11-29 20:57:17]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

No Wait (default):
  The task does not wait on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

[commit-bot: I haz the power, 2016-11-29 20:57:20]

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

[fdoray, 2016-11-29 20:57:23]

The CQ bit was unchecked by fdoray@chromium.org

[fdoray, 2016-11-29 20:57:36]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2016-11-29 20:58:07]

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-11-29 22:59:09]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1480453056021830,
"parent_rev": "4f14d1114ad78111e3b684b4ce4842d3509d4c2c", "commit_rev":
"adb0d0b3c82bbde1f4af50ca9c8cea79256af9fe"}

[commit-bot: I haz the power, 2016-11-29 22:59:39]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

[commit-bot: I haz the power, 2016-11-29 22:59:40]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-11-29 23:02:01]

Description was changed from

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

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

to

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

This CL replaces base::WorkerPool::PostTask() with
base::PostTaskWithTraits(). The following traits are used:

Priority: BACKGROUND
  User won't notice if this task takes an arbitrarily long time
  to complete.

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).

With File IO:
  The task waits on synchronous file IO operations.

With Wait:
  The task waits on things other than synchronous file IO
  operations (e.g. WaitableEvent, ConditionVariable, join a thread,
  join a process, blocking system call that doesn't involve
  interactions with the file system).

BUG=659191

Committed: https://crrev.com/1ed46e5a16b6f0ce4ee88eb1a7fd1a05383261ec
Cr-Commit-Position: refs/heads/master@{#435100}
==========

[commit-bot: I haz the power, 2016-11-29 23:02:02]

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