[reference - do not submit] Always create four pools in TaskSchedulerImpl.

Always create four pools in TaskSchedulerImpl.

Instead of letting callers choose the number of pools and the mapping
between TaskTraits and pool index, always create four pools with
predefined thread priorities.

This change is required to queue tasks before TaskScheduler
initialization.

BUG=690706

[fdoray, 2017-03-15 17:59:43]

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

[commit-bot: I haz the power, 2017-03-15 18:00:19]

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

[fdoray, 2017-03-15 18:06:41]

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

[commit-bot: I haz the power, 2017-03-15 18:07: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-03-15 18:13:22]

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

[commit-bot: I haz the power, 2017-03-15 18:13:23]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[fdoray, 2017-03-15 21:51:30]

Description was changed from

==========
Always create four pools in TaskSchedulerImpl.

BUG=
==========

to

==========
Always create four pools in TaskSchedulerImpl.

Instead of letting callers choose the number of pools and the mapping
between TaskTraits and pool index, always create four pools with
predefined thread priorities.

This change is required to queue tasks before TaskScheduler
initialization.

BUG=690706
==========

[fdoray, 2017-03-16 12:33:39]

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

[commit-bot: I haz the power, 2017-03-16 12:33:52]

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

[fdoray, 2017-03-16 12:34:19]

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

[fdoray, 2017-03-16 12:34:21]

PTAL

[commit-bot: I haz the power, 2017-03-16 12:42:32]

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

[commit-bot: I haz the power, 2017-03-16 12:42:33]

Dry run: Try jobs failed on following builders:
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[gab, 2017-03-20 16:45:53]

This CL is massive =S! Any way to split it up or tips on reviewing order?

[robliao, 2017-03-20 17:05:16]

On 2017/03/20 16:45:53, gab wrote:
> This CL is massive =S! Any way to split it up or tips on reviewing order?

The way to do this is the same way we've been doing the task scheduler :-)

1) Create the new API. Deprecate the old API. Have the old API call the new API.
2) Migrate all callers incrementally.
3) Remove the old API.

[gab, 2017-03-20 17:09:34]

On 2017/03/20 17:05:16, robliao wrote:
> On 2017/03/20 16:45:53, gab wrote:
> > This CL is massive =S! Any way to split it up or tips on reviewing order?
> 
> The way to do this is the same way we've been doing the task scheduler :-)
> 
> 1) Create the new API. Deprecate the old API. Have the old API call the new
API.
> 2) Migrate all callers incrementally.
> 3) Remove the old API.

Right, though I could see why keeping both in parallel could be more burdensome
than the added benefit in this case. So maybe just tips for reviewing are
sufficient?

[robliao, 2017-03-20 17:13:24]

On 2017/03/20 17:09:34, gab wrote:
> On 2017/03/20 17:05:16, robliao wrote:
> > On 2017/03/20 16:45:53, gab wrote:
> > > This CL is massive =S! Any way to split it up or tips on reviewing order?
> > 
> > The way to do this is the same way we've been doing the task scheduler :-)
> > 
> > 1) Create the new API. Deprecate the old API. Have the old API call the new
> API.
> > 2) Migrate all callers incrementally.
> > 3) Remove the old API.
> 
> Right, though I could see why keeping both in parallel could be more
burdensome
> than the added benefit in this case. So maybe just tips for reviewing are
> sufficient?

It makes OWNER reviews in content much easier to go this way. Instead of seeing
a large changelist as we all did, they instead see a targeted CL.

[gab, 2017-03-20 17:52:20]

On 2017/03/20 17:13:24, robliao wrote:
> On 2017/03/20 17:09:34, gab wrote:
> > On 2017/03/20 17:05:16, robliao wrote:
> > > On 2017/03/20 16:45:53, gab wrote:
> > > > This CL is massive =S! Any way to split it up or tips on reviewing
order?
> > > 
> > > The way to do this is the same way we've been doing the task scheduler :-)
> > > 
> > > 1) Create the new API. Deprecate the old API. Have the old API call the
new
> > API.
> > > 2) Migrate all callers incrementally.
> > > 3) Remove the old API.
> > 
> > Right, though I could see why keeping both in parallel could be more
> burdensome
> > than the added benefit in this case. So maybe just tips for reviewing are
> > sufficient?
> 
> It makes OWNER reviews in content much easier to go this way. Instead of
seeing
> a large changelist as we all did, they instead see a targeted CL.

True, @fdoray is it much harder to go that route?

[fdoray, 2017-03-20 20:15:55]

On 2017/03/20 17:52:20, gab wrote:
> On 2017/03/20 17:13:24, robliao wrote:
> > On 2017/03/20 17:09:34, gab wrote:
> > > On 2017/03/20 17:05:16, robliao wrote:
> > > > On 2017/03/20 16:45:53, gab wrote:
> > > > > This CL is massive =S! Any way to split it up or tips on reviewing
> order?
> > > > 
> > > > The way to do this is the same way we've been doing the task scheduler
:-)
> > > > 
> > > > 1) Create the new API. Deprecate the old API. Have the old API call the
> new
> > > API.
> > > > 2) Migrate all callers incrementally.
> > > > 3) Remove the old API.
> > > 
> > > Right, though I could see why keeping both in parallel could be more
> > burdensome
> > > than the added benefit in this case. So maybe just tips for reviewing are
> > > sufficient?
> > 
> > It makes OWNER reviews in content much easier to go this way. Instead of
> seeing
> > a large changelist as we all did, they instead see a targeted CL.
> 
> True, @fdoray is it much harder to go that route?

"Have the old API call the new API." Doesn't work well since the new API is more
restrictive than the old one. It works the other way around:
1) Create the new API. Deprecate the old API. Have the *new API* call the *old
API*.
2) Migrate all callers to the new API incrementally.
3) Remove the old API.

https://codereview.chromium.org/2764603002/