PPAPI: Refactor ppapi test callbacks to ease testing blocking callbacks.

ppapi/proxy/ppb_network_monitor_private_proxy.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 "ppapi/proxy/ppb_network_monitor_private_proxy.h"
 
 #include "ppapi/proxy/enter_proxy.h"
 #include "ppapi/proxy/plugin_proxy_delegate.h"
 #include "ppapi/proxy/ppapi_messages.h"
 #include "ppapi/thunk/ppb_network_monitor_private_api.h"
@@ skipping 80 matching lines @@
     // If that is the first network monitor then send Start message.
     PluginGlobals::Get()->plugin_proxy_delegate()->SendToBrowser(
         new PpapiHostMsg_PPBNetworkMonitor_Start(
             dispatcher->plugin_dispatcher_id()));
 
     // We could have received network list message after sending the
     // previous Stop message. This list is stale now, so reset it
     // here.
     proxy->current_list_ = NULL;
   } else if (proxy->current_list_.get()) {
-    MessageLoop::current()->PostTask(FROM_HERE, base::Bind(
+    MessageLoop::current()->PostTask(FROM_HERE, RunWhileLocked(base::Bind(

[dmichael (off chromium), 2012/04/02 21:15:02]

somewhat unrelated, but causes problems running the tests locally for me, since
I'm building with enable_pepper_threading=1.

[bbudge, 2012/04/04 19:03:00]

Does it also cause problems in normal use? Is there a performance cost for
locking?

[dmichael (off chromium), 2012/04/04 19:50:47]

Yes, but locking is not enabled yet, so RunWhileLocked ultimately just adds a
little function-call overhead. We'll have to do some benchmarking or something
to make sure locking is fast enough, and Graphics3D is going to need some help
to avoid too much locking. In this case, the cost of locking is negligible,
since NetworkLists aren't going to change very frequently.

The real problem here is one of correctness, when locking is enabled. The design
is to always hold the lock while in proxy code. Note that in
OnNetworkListReceived, we unlock the mutex before calling out to the plugin. The
code before this patch means we enter the proxy when the task is run and invokes
OnNetworkListReceived, and we do not have the lock. This is bad because (a) we
probably will have concurrency problems, and (b) we try to _unlock_ the lock in
OnNetworkListReceived, which fails if we don't own the lock.

         &NetworkMonitor::OnNetworkListReceived,
-        result->AsWeakPtr(), proxy->current_list_));
+        result->AsWeakPtr(), proxy->current_list_)));
   }
 
   return result.release()->GetReference();
 }
 
 bool PPB_NetworkMonitor_Private_Proxy::OnMessageReceived(
     const IPC::Message& msg) {
   bool handled = true;
   IPC_BEGIN_MESSAGE_MAP(PPB_NetworkMonitor_Private_Proxy, msg)
     IPC_MESSAGE_HANDLER(PpapiMsg_PPBNetworkMonitor_NetworkList,
@@ skipping 23 matching lines @@
       PluginGlobals::Get()->plugin_proxy_delegate()->SendToBrowser(
           new PpapiHostMsg_PPBNetworkMonitor_Stop(
               dispatcher->plugin_dispatcher_id()));
     }
     current_list_ = NULL;
   }
 }
 
 }  // namespace proxy
 }  // namespace ppapi