Prefer ScopedNestableTaskAllower over manual save/restore

net/socket/client_socket_pool_base_unittest.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/socket/client_socket_pool_base.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/callback.h"
 #include "base/compiler_specific.h"
@@ skipping 1392 matching lines @@
     ASSERT_EQ(OK, result);
 
     if (!within_callback_) {
       test_connect_job_factory_->set_job_type(next_job_type_);
 
       // Don't allow reuse of the socket.  Disconnect it and then release it and
       // run through the MessageLoop once to get it completely released.
       handle_->socket()->Disconnect();
       handle_->Reset();
       {
-        MessageLoop::ScopedNestableTaskAllower nestable(
-            MessageLoop::current());
+        MessageLoop::ScopedNestableTaskAllower allow(MessageLoop::current());
         MessageLoop::current()->RunAllPending();
       }
       within_callback_ = true;

[jar (doing other things), 2012/02/11 03:24:38]

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??

[dhollowa, 2012/02/13 17:44:26]

I've added willchan@ to the CC list.

[willchan no longer on Chromium, 2012/02/14 01:43:42]

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.

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

Done.

       TestCompletionCallback next_job_callback;
       scoped_refptr<TestSocketParams> params(new TestSocketParams());
       int rv = handle_->Init("a",
                              params,
                              kDefaultPriority,
                              next_job_callback.callback(),
                              pool_,
                              BoundNetLog());
       switch (next_job_type_) {
         case TestConnectJob::kMockJob:
           EXPECT_EQ(OK, rv);
           break;
         case TestConnectJob::kMockPendingJob:
           EXPECT_EQ(ERR_IO_PENDING, rv);
 
           // For pending jobs, wait for new socket to be created. This makes
           // sure there are no more pending operations nor any unclosed sockets
           // when the test finishes.
           // We need to give it a little bit of time to run, so that all the
           // operations that happen on timers (e.g. cleanup of idle
           // connections) can execute.
           {
-            MessageLoop::ScopedNestableTaskAllower nestable(
+            MessageLoop::ScopedNestableTaskAllower allow(
                 MessageLoop::current());
             base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(10));

[jar (doing other things), 2012/02/11 03:24:38]

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.

[jar (doing other things), 2012/02/14 01:51:43]

What about removing this allow call??

On 2012/02/11 03:24:38, jar wrote:

[willchan no longer on Chromium, 2012/02/14 01:54: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:

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

Done.

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

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

             EXPECT_EQ(OK, next_job_callback.WaitForResult());
           }
           break;
         default:
           FAIL() << "Unexpected job type: " << next_job_type_;
           break;
       }
     }
   }
 
@@ skipping 1906 matching lines @@
   // The hung connect job should still be there, but everything else should be
   // complete.
   EXPECT_EQ(1, pool_->NumConnectJobsInGroup("a"));
   EXPECT_EQ(0, pool_->IdleSocketCountInGroup("a"));
   EXPECT_EQ(1, pool_->NumActiveSocketsInGroup("a"));
 }
 
 }  // namespace
 
 }  // namespace net