Disallow nesting on some BrowserThreads.

Disallow nesting on some BrowserThreads.

This CL disallows nesting on BrowserThreads that will be migrated
to TaskScheduler. Running a nested loop or calling
Add/RemoveNestingObserver on these threads will result in a crash.

To our knowledge, no code runs a nested loop on BrowserThreads that
will be migrated to TaskScheduler. This CL will help us confirm that
in the wild.

BUG=653916
Committed: https://crrev.com/6d547b63b4176785a3caf5019c055173a28535e8
Cr-Commit-Position: refs/heads/master@{#424749}

[fdoray, 2016-10-11 16:04:51]

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

[commit-bot: I haz the power, 2016-10-11 16:05:13]

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

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

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

[commit-bot: I haz the power, 2016-10-11 17:17:21]

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-10-11 17:32:45]

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

[commit-bot: I haz the power, 2016-10-11 17:32:46]

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

[fdoray, 2016-10-11 18:46:41]

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

[fdoray, 2016-10-11 18:46:42]

PTAL

[jam, 2016-10-11 19:25:52]

Sorry for repeating the question from the other cl, but I saw this after.

I'm curious the IO thread uses nestable message loops?

[fdoray, 2016-10-11 19:39:14]

On 2016/10/11 19:25:52, jam wrote:
> Sorry for repeating the question from the other cl, but I saw this after.
> 
> I'm curious the IO thread uses nestable message loops?

I don't know if the IO thread uses nestable message loops. We don't need to
disallow it since, unlike other browser threads, we don't plan to migrate the IO
thread to TaskScheduler anytime soon. Do you want me to find out whether nested
loops are used on the IO thread?

[jam, 2016-10-11 21:25:45]

lgtm

On 2016/10/11 19:39:14, fdoray wrote:
> On 2016/10/11 19:25:52, jam wrote:
> > Sorry for repeating the question from the other cl, but I saw this after.
> > 
> > I'm curious the IO thread uses nestable message loops?
> 
> I don't know if the IO thread uses nestable message loops. We don't need to
> disallow it since, unlike other browser threads, we don't plan to migrate the
IO
> thread to TaskScheduler anytime 

I'm curious why? Is it because you want TaskScheduler to just be a generic
message pump and not have to worry about OS-specific messages like window
message, I/O etc?

> Do you want me to find out whether nested
> loops are used on the IO thread?

no need to

[fdoray, 2016-10-12 15:46:25]

On 2016/10/11 21:25:45, jam wrote:
> lgtm
> 
> On 2016/10/11 19:39:14, fdoray wrote:
> > On 2016/10/11 19:25:52, jam wrote:
> > > Sorry for repeating the question from the other cl, but I saw this after.
> > > 
> > > I'm curious the IO thread uses nestable message loops?
> > 
> > I don't know if the IO thread uses nestable message loops. We don't need to
> > disallow it since, unlike other browser threads, we don't plan to migrate
the
> IO
> > thread to TaskScheduler anytime 
> 
> I'm curious why? Is it because you want TaskScheduler to just be a generic
> message pump and not have to worry about OS-specific messages like window
> message, I/O etc?
> 
> > Do you want me to find out whether nested
> > loops are used on the IO thread?
> 
> no need to

To my knowledge, it's because the IO thread has subtle interactions with the OS
that we don't want to mess with. I asked robliao@ to provide a more thorough
answer.

[fdoray, 2016-10-12 15:46:32]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2016-10-12 15:46:43]

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-10-12 15:52:59]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-10-12 15:55:30]

Description was changed from

==========
Disallow nesting on some BrowserThreads.

This CL disallows nesting on BrowserThreads that will be migrated
to TaskScheduler. Running a nested loop or calling
Add/RemoveNestingObserver on these threads will result in a crash.

To our knowledge, no code runs a nested loop on BrowserThreads that
will be migrated to TaskScheduler. This CL will help us confirm that
in the wild.

BUG=653916
==========

to

==========
Disallow nesting on some BrowserThreads.

This CL disallows nesting on BrowserThreads that will be migrated
to TaskScheduler. Running a nested loop or calling
Add/RemoveNestingObserver on these threads will result in a crash.

To our knowledge, no code runs a nested loop on BrowserThreads that
will be migrated to TaskScheduler. This CL will help us confirm that
in the wild.

BUG=653916

Committed: https://crrev.com/6d547b63b4176785a3caf5019c055173a28535e8
Cr-Commit-Position: refs/heads/master@{#424749}
==========

[commit-bot: I haz the power, 2016-10-12 15:55:31]

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

[robliao, 2016-10-12 17:13:53]

On 2016/10/12 15:46:25, fdoray wrote:
> On 2016/10/11 21:25:45, jam wrote:
> > lgtm
> > 
> > On 2016/10/11 19:39:14, fdoray wrote:
> > > On 2016/10/11 19:25:52, jam wrote:
> > > > Sorry for repeating the question from the other cl, but I saw this
after.
> > > > 
> > > > I'm curious the IO thread uses nestable message loops?
> > > 
> > > I don't know if the IO thread uses nestable message loops. We don't need
to
> > > disallow it since, unlike other browser threads, we don't plan to migrate
> the
> > IO
> > > thread to TaskScheduler anytime 
> > 
> > I'm curious why? Is it because you want TaskScheduler to just be a generic
> > message pump and not have to worry about OS-specific messages like window
> > message, I/O etc?
> > 
> > > Do you want me to find out whether nested
> > > loops are used on the IO thread?
> > 
> > no need to
> 
> To my knowledge, it's because the IO thread has subtle interactions with the
OS
> that we don't want to mess with. I asked robliao@ to provide a more thorough
> answer.

The main reason why we deferred migrating the IO thread is primarily because it
required callback support to handle the IPCs, something not originally handled
in the scheduler thread pools.
Not handling callbacks was sufficient to handle all browser threads except for
the UI and IO threads. All other browser threads didn't have this requirement.

We can investigate what it would take to move the IO thread after we've removed
the other named browser threads.