Prefer ScopedNestableTaskAllower over manual save/restore

Prefer ScopedNestableTaskAllower over manual save/restore

Cleanup.  Changes various calls sites to use the
ScopedNestableTaskAllower class to save/restore nestable task
state.

BUG=None
TEST=Existing unit tests
[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=121914

[dhollowa, 2012-02-11 02:08:12]

Hello various owners!  This is what I had in mind:

jar -> base
scottbyer -> print
sky -> sessions, views
akalin -> sync
rsleevi -> net
brettw -> ppapi
tony -> webkit

Thanks.

[Ryan Sleevi, 2012-02-11 02:17:21]

net/ LGTM, but a few comments below

https://chromiumcodereview.appspot.com/9384024/diff/1/base/message_loop.h
File base/message_loop.h (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/base/message_loop.h#new...
base/message_loop.h:74: //   // Process |hr| (the result returned by
DoDragDrop()).
Comment bug: |hr| is now out of scope once outside of the block

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/sync/pro...
File chrome/browser/sync/profile_sync_service_harness.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/sync/pro...
chrome/browser/sync/profile_sync_service_harness.cc:759: if
(timeout_signal->Abort()) {
Is it any concern that this call now runs while nestable tasks are still
allowed?

https://chromiumcodereview.appspot.com/9384024/diff/1/webkit/plugins/ppapi/pp...
File webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/webkit/plugins/ppapi/pp...
webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc:96: return
state_protector->result();
Also here - state_protector->result() runs while nestable loops are still
allowed.

[Scott Byer, 2012-02-11 02:17:57]

LGTM for 

chrome/browser/printing/print_job.cc
chrome/browser/printing/print_view_manager.cc

On 2012/02/11 02:08:12, dhollowa wrote:
> Hello various owners!  This is what I had in mind:
> 
> jar -> base
> scottbyer -> print
> sky -> sessions, views
> akalin -> sync
> rsleevi -> net
> brettw -> ppapi
> tony -> webkit
> 
> Thanks.

[tony, 2012-02-11 02:56:20]

webkit LGTM except for the part rsleevi mentioned.  Not sure if it matters there
so I'm OK with either adding {} or not.

[jar (doing other things), 2012-02-11 03:24:37]

I detest nested message loops, and their use is endlessly fraught with peril. 
All code above the invocation must be reentrant (which is super hard to do), and
the pattern of posting a quit() message is equally perilous (since other folks
can also nest... and you can't tell what loop you terminate <sigh>  ).

I only put in the setter API to allow the nesting under a lot of duress, and
hoped folks will predominantly avoid using them.  I'm happy that you've kept the
interface large and easy to spot (via grep), and that you've made the on/off
less error prone (at least in the 4 line snippet around the set/restore state).

Nice job. ;-)

If anything, I'd suggest adding an alarming and scary word to the helper class
you defined, such as "Dangerous" "UsedWithExtremeCaution."  I really don't want
folks to be casual about doing this setting... as the bugs are painful and
confusing to diagnose (no one reads code expecting it to be re-entrant :-(  ).


As a result, whenever I look at code that *uses* this stuff, I'm super
suspicious of bugs.  With that in mind, I've added a bunch of questions for
folks that are more savvy about the necessity of the uses.

Bottom line: I like your change.  Consider making the class name bigger and
scarier, to scare away casual users.  Hopefully others (familiar the files) can
comment on the plausible bugs I've cited.

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/automati...
File chrome/browser/automation/automation_provider_win.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/automati...
chrome/browser/automation/automation_provider_win.cc:153:
views::AcceleratorHandler handler;
nit: although this mimics the existing code... IMO, we should construct the
handler outside of the scope of the nestable message loop, just so that we don't
accidentally(?) have any potential for running a nested loop (invisibly).

I'd suggest exchanging lines 152 and 153.

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/printing...
File chrome/browser/printing/print_job.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/printing...
chrome/browser/printing/print_job.cc:201: quit_task.Start(FROM_HERE,
TimeDelta::FromMilliseconds(timeout_ms),
This is pretty evil/problematic... though not related to this CL change.  This
pushes a quite message into the pending message queue. If *any* other user makes
yet another recursive  (nested) message loop run, then *they* can be terminated
by this task.

The pattern of posting a quite task this way is more than fraught with peril,
IMO.

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/printing...
File chrome/browser/printing/print_view_manager.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/printing...
chrome/browser/printing/print_view_manager.cc:549: MessageLoop::current(),
&MessageLoop::Quit);
(again, orthogonal to your CL):

This is a terrible and risky pattern.  The quit message can terminate *any*
nested message loop, and not just the one that is visible in line 556.

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/sync/pro...
File chrome/browser/sync/profile_sync_service_harness.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/sync/pro...
chrome/browser/sync/profile_sync_service_harness.cc:749: 
nit: You probably don't need the black line.

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/sync/pro...
chrome/browser/sync/profile_sync_service_harness.cc:759: if
(timeout_signal->Abort()) {
+1

Please enclose lines 751 to 757 in a local scope.

On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> Is it any concern that this call now runs while nestable tasks are still
> allowed?

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
File chrome/browser/ui/views/simple_message_box_views.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
chrome/browser/ui/views/simple_message_box_views.cc:71:
g_browser_process->ReleaseModule();
nit/curious question: What are the potential side effects of this
ReleaseModule()?  How much destruction can take place, or is it all just posted
events, and that is why it is safe to do now (and not while we're in a
sub-loop)?

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
File chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
(right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
nit: Does this actually induce a nested message loop?

If so, it might be good to make that much more apparent in the underlying code,
as the code needs to be re-entrant.

I tried to look at what I *thought* was the code... but it was not immediately
clear when/how it created a sub-message loop.

https://chromiumcodereview.appspot.com/9384024/diff/1/content/browser/downloa...
File content/browser/download/drag_download_file.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/content/browser/downloa...
content/browser/download/drag_download_file.cc:228:
MessageLoop::current()->Run();
This looks suspiciously like a bug... but I'm not sure.

I suspect we should have line 229 that does:
is_running_nested_message_loop_ = false.

without it, I'm wary that a call in line 234 will post a spurious Quit()
message.


Alternatively, I'd be OK with asserting (here) that it was set to false via line
235.  ...but looking at the logic, I'm confused about whether it is evyr
possible to reach lien 234 without having is_running_nested_message_loop_ .  A
brief read of the code (perhaps too brief) suggests that 231 is only called when
in a nested message loop... but I'm not sure at all.

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
File net/socket/client_socket_pool_base_unittest.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
net/socket/client_socket_pool_base_unittest.cc:1416: within_callback_ = true;
This is a *little* scary.  The names (and pattern at line 1405) suggests that
this is used to preclude recursion.... at the same time, we allowed recursion
(potentially) on line 1414.

Could someone familiar with this code validate this is correct and as planned??

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
net/socket/client_socket_pool_base_unittest.cc:1441:
base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));
This doesn't make sense to me.  All we're doing is sleeping (blocking the
current thread).  We're not running a task.  I think we should remove the
Allower completely.

...alternatively... you could investigate the history of this code... and see
how we got here... and see if we dropped some critical code on the floor.

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/transport_cl...
File net/socket/transport_client_socket_pool_unittest.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/transport_cl...
net/socket/transport_client_socket_pool_unittest.cc:803: within_callback_ =
true;
again... this looks like a pattern to prevent recursion (re: line 794 and line
803), but we potentially recurse via lines 801.

If we really wanted to prevent recursion, wouldn't we have set line 803 before
we did the RunAllPending()?

Looking at the code some more, I see that within_callback_ is seemingly only set
to true, and never reset to false.  Does this mean a better name would have been
ran_callback_?

https://chromiumcodereview.appspot.com/9384024/diff/1/webkit/plugins/ppapi/pp...
File webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/webkit/plugins/ppapi/pp...
webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc:96: return
state_protector->result();
+1

Please put lines 91 and 92 into a local scope.

On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> Also here - state_protector->result() runs while nestable loops are still
> allowed.

[jar (doing other things), 2012-02-11 03:25:52]

Scott, could you comment on my questions in those files?

Thanks,

Jim

On Fri, Feb 10, 2012 at 6:17 PM, <[email protected]> wrote:

> LGTM for
>
> chrome/browser/printing/print_**job.cc
> chrome/browser/printing/print_**view_manager.cc
>
>
> On 2012/02/11 02:08:12, dhollowa wrote:
>
>> Hello various owners!  This is what I had in mind:
>>
>
>  jar -> base
>> scottbyer -> print
>> sky -> sessions, views
>> akalin -> sync
>> rsleevi -> net
>> brettw -> ppapi
>> tony -> webkit
>>
>
>  Thanks.
>>
>
>
>
http://codereview.chromium.**org/9384024/<http://codereview.chromium.org/9384...
>

[brettw, 2012-02-11 05:25:10]

ppapi lgtm

[dhollowa, 2012-02-13 17:44:25]

http://codereview.chromium.org/9384024/diff/1/base/message_loop.h
File base/message_loop.h (right):

http://codereview.chromium.org/9384024/diff/1/base/message_loop.h#newcode74
base/message_loop.h:74: //   // Process |hr| (the result returned by
DoDragDrop()).
On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> Comment bug: |hr| is now out of scope once outside of the block

Done.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/automation/autom...
File chrome/browser/automation/automation_provider_win.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/automation/autom...
chrome/browser/automation/automation_provider_win.cc:153:
views::AcceleratorHandler handler;
On 2012/02/11 03:24:38, jar wrote:
> nit: although this mimics the existing code... IMO, we should construct the
> handler outside of the scope of the nestable message loop, just so that we
don't
> accidentally(?) have any potential for running a nested loop (invisibly).
> 
> I'd suggest exchanging lines 152 and 153.

Done.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_j...
File chrome/browser/printing/print_job.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_j...
chrome/browser/printing/print_job.cc:201: quit_task.Start(FROM_HERE,
TimeDelta::FromMilliseconds(timeout_ms),
On 2012/02/11 03:24:38, jar wrote:
> This is pretty evil/problematic... though not related to this CL change.  This
> pushes a quite message into the pending message queue. If *any* other user
makes
> yet another recursive  (nested) message loop run, then *they* can be
terminated
> by this task.
> 
> The pattern of posting a quite task this way is more than fraught with peril,
> IMO.

Looks like this was added by Darin.  I'm not sure of the history.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_v...
File chrome/browser/printing/print_view_manager.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_v...
chrome/browser/printing/print_view_manager.cc:549: MessageLoop::current(),
&MessageLoop::Quit);
On 2012/02/11 03:24:38, jar wrote:
> (again, orthogonal to your CL):
> 
> This is a terrible and risky pattern.  The quit message can terminate *any*
> nested message loop, and not just the one that is visible in line 556.

(Also added by Darin.)

http://codereview.chromium.org/9384024/diff/1/chrome/browser/sync/profile_syn...
File chrome/browser/sync/profile_sync_service_harness.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/sync/profile_syn...
chrome/browser/sync/profile_sync_service_harness.cc:749: 
On 2012/02/11 03:24:38, jar wrote:
> nit: You probably don't need the black line.

Done.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/sync/profile_syn...
chrome/browser/sync/profile_sync_service_harness.cc:759: if
(timeout_signal->Abort()) {
On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> Is it any concern that this call now runs while nestable tasks are still
> allowed?

I'd left it out for readability, the signal manipulation is not relevant to the
nestability.  But I'm fine to scope it explicitly too.  So have done that.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/sync/profile_syn...
chrome/browser/sync/profile_sync_service_harness.cc:759: if
(timeout_signal->Abort()) {
On 2012/02/11 03:24:38, jar wrote:
> +1
> 
> Please enclose lines 751 to 757 in a local scope.
> 
> On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> > Is it any concern that this call now runs while nestable tasks are still
> > allowed?
> 

Done.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/ui/views/simple_...
File chrome/browser/ui/views/simple_message_box_views.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/ui/views/simple_...
chrome/browser/ui/views/simple_message_box_views.cc:71:
g_browser_process->ReleaseModule();
On 2012/02/11 03:24:38, jar wrote:
> nit/curious question: What are the potential side effects of this
> ReleaseModule()?  How much destruction can take place, or is it all just
posted
> events, and that is why it is safe to do now (and not while we're in a
> sub-loop)?

This is meant to match the |AddRefModule| at line 60, a guard against shutdown
with the dialog up.  If this is the last "release" then quit messages are posted
to the IO thread and the main UI thread is "Quit".  This seems ok.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/ui/views/tab_con...
File chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
(right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/ui/views/tab_con...
chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
On 2012/02/11 03:24:38, jar wrote:
> nit: Does this actually induce a nested message loop?
> 
> If so, it might be good to make that much more apparent in the underlying
code,
> as the code needs to be re-entrant.
> 
> I tried to look at what I *thought* was the code... but it was not immediately
> clear when/how it created a sub-message loop.

sky will be the best person to comment here.  But it looks like the message loop
is created at ash/drag_drop/drag_drop_controller.cc:54, where messages are
dispatched back to the host framework.

http://codereview.chromium.org/9384024/diff/1/content/browser/download/drag_d...
File content/browser/download/drag_download_file.cc (right):

http://codereview.chromium.org/9384024/diff/1/content/browser/download/drag_d...
content/browser/download/drag_download_file.cc:228:
MessageLoop::current()->Run();
On 2012/02/11 03:24:38, jar wrote:
> This looks suspiciously like a bug... but I'm not sure.
> 
> I suspect we should have line 229 that does:
> is_running_nested_message_loop_ = false.
> 
> without it, I'm wary that a call in line 234 will post a spurious Quit()
> message.
> 
> 
> Alternatively, I'd be OK with asserting (here) that it was set to false via
line
> 235.  ...but looking at the logic, I'm confused about whether it is evyr
> possible to reach lien 234 without having is_running_nested_message_loop_ .  A
> brief read of the code (perhaps too brief) suggests that 231 is only called
when
> in a nested message loop... but I'm not sure at all.

Done.  I've added DCHECK to verify the logic.  If this trips we might consider
using |MessageLoop::IsNested| instead.

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
File net/socket/client_socket_pool_base_unittest.cc (right):

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
net/socket/client_socket_pool_base_unittest.cc:1416: within_callback_ = true;
On 2012/02/11 03:24:38, jar wrote:
> This is a *little* scary.  The names (and pattern at line 1405) suggests that
> this is used to preclude recursion.... at the same time, we allowed recursion
> (potentially) on line 1414.
> 
> Could someone familiar with this code validate this is correct and as
planned??

I've added willchan@ to the CC list.

http://codereview.chromium.org/9384024/diff/1/webkit/plugins/ppapi/ppb_flash_...
File webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc (right):

http://codereview.chromium.org/9384024/diff/1/webkit/plugins/ppapi/ppb_flash_...
webkit/plugins/ppapi/ppb_flash_message_loop_impl.cc:96: return
state_protector->result();
On 2012/02/11 03:24:38, jar wrote:
> +1
> 
> Please put lines 91 and 92 into a local scope.
> 
> On 2012/02/11 02:17:22, Ryan Sleevi wrote:
> > Also here - state_protector->result() runs while nestable loops are still
> > allowed.
> 

Done.

[dhollowa, 2012-02-13 17:51:21]

On 2012/02/11 03:24:37, jar wrote:
> [...]
> If anything, I'd suggest adding an alarming and scary word to the helper class
> you defined, such as "Dangerous" "UsedWithExtremeCaution."  I really don't
want
> folks to be casual about doing this setting... as the bugs are painful and
> confusing to diagnose (no one reads code expecting it to be re-entrant :-(  ).
> [...]

I've added a cautionary comment to the
|SetNestableTasksAllowed/NestableTasksAllowed| declarations.  Hopefully this is
sufficient.  I was uncomfortable adding big scary words to the already long
names of the methods and scoper class.  Would using the namespace "subtle" be
appropriate here?  I'm happy to add if you feel strongly.

Thanks for the detailed review.

[jar (doing other things), 2012-02-13 18:03:01]

Darin,

Can you take a look at the snippets below that are attributed to you?

thanks,

Jim

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_j...
File chrome/browser/printing/print_job.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_j...
chrome/browser/printing/print_job.cc:201: quit_task.Start(FROM_HERE,
TimeDelta::FromMilliseconds(timeout_ms),
Darin,

This code looks pretty risky... especially since there are other folks (like in
UI) that are using nested tasks (which the Quit() can terminate).

Can you justify why this is reasonable?

Thanks,

Jim

On 2012/02/13 17:44:26, dhollowa wrote:
> On 2012/02/11 03:24:38, jar wrote:
> > This is pretty evil/problematic... though not related to this CL change. 
This
> > pushes a quite message into the pending message queue. If *any* other user
> makes
> > yet another recursive  (nested) message loop run, then *they* can be
> terminated
> > by this task.
> > 
> > The pattern of posting a quite task this way is more than fraught with
peril,
> > IMO.
> 
> Looks like this was added by Darin.  I'm not sure of the history.

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_v...
File chrome/browser/printing/print_view_manager.cc (right):

http://codereview.chromium.org/9384024/diff/1/chrome/browser/printing/print_v...
chrome/browser/printing/print_view_manager.cc:549: MessageLoop::current(),
&MessageLoop::Quit);
Darin,

Was this your code?  (or you just updated it).  

Is there a bug to remove it?

Thanks,

Jim

On 2012/02/13 17:44:26, dhollowa wrote:
> On 2012/02/11 03:24:38, jar wrote:
> > (again, orthogonal to your CL):
> > 
> > This is a terrible and risky pattern.  The quit message can terminate *any*
> > nested message loop, and not just the one that is visible in line 556.
> 
> (Also added by Darin.)

[sky, 2012-02-13 18:28:10]

LGTM

[akalin, 2012-02-13 22:23:31]

sync lgtm

[dhollowa, 2012-02-14 01:31:45]

jar: Ok if I land this CL and follow up on the print issues out-of-band?

[willchan no longer on Chromium, 2012-02-14 01:43:41]

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
File net/socket/client_socket_pool_base_unittest.cc (right):

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
net/socket/client_socket_pool_base_unittest.cc:1416: within_callback_ = true;
On 2012/02/13 17:44:26, dhollowa wrote:
> On 2012/02/11 03:24:38, jar wrote:
> > This is a *little* scary.  The names (and pattern at line 1405) suggests
that
> > this is used to preclude recursion.... at the same time, we allowed
recursion
> > (potentially) on line 1414.
> > 
> > Could someone familiar with this code validate this is correct and as
> planned??
> 
> I've added willchan@ to the CC list.

I've looked at it and it's minorly scary as jar@ says. My understanding is this
changelist is not a behavior change, so your change is fine by me. It's minor
since the amount of code executed within this test is minimal, so the
theoretical danger of nested message loops should not happen. However, we should
fix it at some point when we have time. Perhaps file a cleanup bug against
Internal-Network-HTTP and link to the bug here.

[jar (doing other things), 2012-02-14 01:51:42]

I'm fine with you landing...  as it is an improvement.  LGTM

Please consider removing the extra allow you have illuminated (see comment
below).

sky: Please take a look, and see if this is as close to the nesting as we can go
(so that the scope in which nesting might take place is minimal).

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
File chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
(right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
Sky@

Do you think this is as close as you can get to the running of the nested
message loops?

Thanks,

Jim

On 2012/02/13 17:44:26, dhollowa wrote:
> On 2012/02/11 03:24:38, jar wrote:
> > nit: Does this actually induce a nested message loop?
> > 
> > If so, it might be good to make that much more apparent in the underlying
> code,
> > as the code needs to be re-entrant.
> > 
> > I tried to look at what I *thought* was the code... but it was not
immediately
> > clear when/how it created a sub-message loop.
> 
> sky will be the best person to comment here.  But it looks like the message
loop
> is created at ash/drag_drop/drag_drop_controller.cc:54, where messages are
> dispatched back to the host framework.

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
File net/socket/client_socket_pool_base_unittest.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
net/socket/client_socket_pool_base_unittest.cc:1441:
base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));
What about removing this allow call??

On 2012/02/11 03:24:38, jar wrote:
> This doesn't make sense to me.  All we're doing is sleeping (blocking the
> current thread).  We're not running a task.  I think we should remove the
> Allower completely.
> 
> ...alternatively... you could investigate the history of this code... and see
> how we got here... and see if we dropped some critical code on the floor.

[willchan no longer on Chromium, 2012-02-14 01:54:09]

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
File net/socket/client_socket_pool_base_unittest.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
net/socket/client_socket_pool_base_unittest.cc:1441:
base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));
Jim's suggestion sounds correct to me here, we can get rid of the
ScopedNestableTaskAllower.

On 2012/02/14 01:51:43, jar wrote:
> What about removing this allow call??
> 
> On 2012/02/11 03:24:38, jar wrote:
> > This doesn't make sense to me.  All we're doing is sleeping (blocking the
> > current thread).  We're not running a task.  I think we should remove the
> > Allower completely.
> > 
> > ...alternatively... you could investigate the history of this code... and
see
> > how we got here... and see if we dropped some critical code on the floor.
>

[dhollowa, 2012-02-14 03:19:49]

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
File net/socket/client_socket_pool_base_unittest.cc (right):

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
net/socket/client_socket_pool_base_unittest.cc:1416: within_callback_ = true;
On 2012/02/14 01:43:42, willchan wrote:
> On 2012/02/13 17:44:26, dhollowa wrote:
> > On 2012/02/11 03:24:38, jar wrote:
> > > This is a *little* scary.  The names (and pattern at line 1405) suggests
> that
> > > this is used to preclude recursion.... at the same time, we allowed
> recursion
> > > (potentially) on line 1414.
> > > 
> > > Could someone familiar with this code validate this is correct and as
> > planned??
> > 
> > I've added willchan@ to the CC list.
> 
> I've looked at it and it's minorly scary as jar@ says. My understanding is
this
> changelist is not a behavior change, so your change is fine by me. It's minor
> since the amount of code executed within this test is minimal, so the
> theoretical danger of nested message loops should not happen. However, we
should
> fix it at some point when we have time. Perhaps file a cleanup bug against
> Internal-Network-HTTP and link to the bug here.

Done.

http://codereview.chromium.org/9384024/diff/1/net/socket/client_socket_pool_b...
net/socket/client_socket_pool_base_unittest.cc:1441:
base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));
On 2012/02/14 01:54:10, willchan wrote:
> Jim's suggestion sounds correct to me here, we can get rid of the
> ScopedNestableTaskAllower.
> 
> On 2012/02/14 01:51:43, jar wrote:
> > What about removing this allow call??
> > 
> > On 2012/02/11 03:24:38, jar wrote:
> > > This doesn't make sense to me.  All we're doing is sleeping (blocking the
> > > current thread).  We're not running a task.  I think we should remove the
> > > Allower completely.
> > > 
> > > ...alternatively... you could investigate the history of this code... and
> see
> > > how we got here... and see if we dropped some critical code on the floor.
> > 
> 

Done.

[sky, 2012-02-14 04:45:05]

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
File chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
(right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
On 2012/02/14 01:51:43, jar wrote:
> Sky@
> 
> Do you think this is as close as you can get to the running of the nested
> message loops?
> 
> Thanks,
> 
> Jim
> 
> On 2012/02/13 17:44:26, dhollowa wrote:
> > On 2012/02/11 03:24:38, jar wrote:
> > > nit: Does this actually induce a nested message loop?
> > > 
> > > If so, it might be good to make that much more apparent in the underlying
> > code,
> > > as the code needs to be re-entrant.
> > > 
> > > I tried to look at what I *thought* was the code... but it was not
> immediately
> > > clear when/how it created a sub-message loop.
> > 
> > sky will be the best person to comment here.  But it looks like the message
> loop
> > is created at ash/drag_drop/drag_drop_controller.cc:54, where messages are
> > dispatched back to the host framework.
> 

DragDropController::StartDragAndDrop is closer (in ash/drag_drop).

[dhollowa, 2012-02-14 05:42:19]

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
File chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
(right):

https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
On 2012/02/14 04:45:05, sky wrote:
> On 2012/02/14 01:51:43, jar wrote:
> > Sky@
> > 
> > Do you think this is as close as you can get to the running of the nested
> > message loops?
> > 
> > Thanks,
> > 
> > Jim
> > 
> > On 2012/02/13 17:44:26, dhollowa wrote:
> > > On 2012/02/11 03:24:38, jar wrote:
> > > > nit: Does this actually induce a nested message loop?
> > > > 
> > > > If so, it might be good to make that much more apparent in the
underlying
> > > code,
> > > > as the code needs to be re-entrant.
> > > > 
> > > > I tried to look at what I *thought* was the code... but it was not
> > immediately
> > > > clear when/how it created a sub-message loop.
> > > 
> > > sky will be the best person to comment here.  But it looks like the
message
> > loop
> > > is created at ash/drag_drop/drag_drop_controller.cc:54, where messages are
> > > dispatched back to the host framework.
> > 
> 
> DragDropController::StartDragAndDrop is closer (in ash/drag_drop).

Shall I move the scoper there then?  Or would you like to handle it?

[dhollowa, 2012-02-14 16:35:50]

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
File net/socket/client_socket_pool_base_unittest.cc (right):

https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socke...
net/socket/client_socket_pool_base_unittest.cc:1441:
base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));
On 2012/02/14 03:19:49, dhollowa wrote:
> On 2012/02/14 01:54:10, willchan wrote:
> > Jim's suggestion sounds correct to me here, we can get rid of the
> > ScopedNestableTaskAllower.
> > 
> > On 2012/02/14 01:51:43, jar wrote:
> > > What about removing this allow call??
> > > 
> > > On 2012/02/11 03:24:38, jar wrote:
> > > > This doesn't make sense to me.  All we're doing is sleeping (blocking
the
> > > > current thread).  We're not running a task.  I think we should remove
the
> > > > Allower completely.
> > > > 
> > > > ...alternatively... you could investigate the history of this code...
and
> > see
> > > > how we got here... and see if we dropped some critical code on the
floor.
> > > 
> > 
> 
> Done.

I had to restore the ScopedNestableTaskAllower because removing it hung the
ClientSocketPoolBaseTest.RequestPendingJobTwice test.

[sky, 2012-02-14 20:28:55]

\On Mon, Feb 13, 2012 at 9:42 PM,  <[email protected]> wrote:
>
>
https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
> File
> chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc
> (right):
>
>
https://chromiumcodereview.appspot.com/9384024/diff/1/chrome/browser/ui/views...
> chrome/browser/ui/views/tab_contents/native_tab_contents_view_aura.cc:217:
> result_op = aura::client::GetDragDropClient()->StartDragAndDrop(
> On 2012/02/14 04:45:05, sky wrote:
>>
>> On 2012/02/14 01:51:43, jar wrote:
>> > Sky@
>> >
>> > Do you think this is as close as you can get to the running of the
>
> nested
>>
>> > message loops?
>> >
>> > Thanks,
>> >
>> > Jim
>> >
>> > On 2012/02/13 17:44:26, dhollowa wrote:
>> > > On 2012/02/11 03:24:38, jar wrote:
>> > > > nit: Does this actually induce a nested message loop?
>> > > >
>> > > > If so, it might be good to make that much more apparent in the
>
> underlying
>>
>> > > code,
>> > > > as the code needs to be re-entrant.
>> > > >
>> > > > I tried to look at what I *thought* was the code... but it was
>
> not
>>
>> > immediately
>> > > > clear when/how it created a sub-message loop.
>> > >
>> > > sky will be the best person to comment here.  But it looks like
>
> the message
>>
>> > loop
>> > > is created at ash/drag_drop/drag_drop_controller.cc:54, where
>
> messages are
>>
>> > > dispatched back to the host framework.
>> >
>
>
>> DragDropController::StartDragAndDrop is closer (in ash/drag_drop).
>
>
> Shall I move the scoper there then?  Or would you like to handle it?

Go for it.

  -Scott

[willchan no longer on Chromium, 2012-02-14 20:31:39]

On Tue, Feb 14, 2012 at 8:35 AM, <[email protected]> wrote:

>
> https://chromiumcodereview.**appspot.com/9384024/diff/1/**
>
net/socket/client_socket_pool_**base_unittest.cc<https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socket_pool_base_unittest.cc>
> File net/socket/client_socket_pool_**base_unittest.cc (right):
>
> https://chromiumcodereview.**appspot.com/9384024/diff/1/**
>
net/socket/client_socket_pool_**base_unittest.cc#newcode1441<https://chromiumcodereview.appspot.com/9384024/diff/1/net/socket/client_socket_pool_base_unittest.cc#newcode1441>
> net/socket/client_socket_pool_**base_unittest.cc:1441:
> base::PlatformThread::Sleep(**base::TimeDelta::**FromMilliseconds(10));
> On 2012/02/14 03:19:49, dhollowa wrote:
>
>> On 2012/02/14 01:54:10, willchan wrote:
>> > Jim's suggestion sounds correct to me here, we can get rid of the
>> > ScopedNestableTaskAllower.
>> >
>> > On 2012/02/14 01:51:43, jar wrote:
>> > > What about removing this allow call??
>> > >
>> > > On 2012/02/11 03:24:38, jar wrote:
>> > > > This doesn't make sense to me.  All we're doing is sleeping
>>
> (blocking the
>
>> > > > current thread).  We're not running a task.  I think we should
>>
> remove the
>
>> > > > Allower completely.
>> > > >
>> > > > ...alternatively... you could investigate the history of this
>>
> code... and
>
>> > see
>> > > > how we got here... and see if we dropped some critical code on
>>
> the floor.
>
>> > >
>> >
>>
>
>  Done.
>>
>
> I had to restore the ScopedNestableTaskAllower because removing it hung
> the ClientSocketPoolBaseTest.**RequestPendingJobTwice test.
>

I don't understand why, but OK. It's not your fault in any case. Please add
it to the existing bug you created for that file. We'll fix it in the
future.


>
>
https://chromiumcodereview.**appspot.com/9384024/<https://chromiumcodereview....
>