Enable pepper threading by default.

ppapi/proxy/ppb_testing_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_testing_proxy.h"
 
 #include "base/message_loop.h"
 #include "ppapi/c/dev/ppb_testing_dev.h"
 #include "ppapi/proxy/enter_proxy.h"
 #include "ppapi/proxy/plugin_dispatcher.h"
@@ skipping 36 matching lines @@
   PP_Bool result = PP_FALSE;
   dispatcher->Send(new PpapiHostMsg_PPBTesting_ReadImageData(
       API_ID_PPB_TESTING, graphics_2d_object->host_resource(),
       image_object->host_resource(), *top_left, &result));
   return result;
 }
 
 void RunMessageLoop(PP_Instance instance) {
   MessageLoop::ScopedNestableTaskAllower allow(MessageLoop::current());
   // TODO(dmichael): We should probably assert that this is the main thread.
+  ProxyAutoLock lock;

[dmichael (off chromium), 2012/11/06 03:00:02]

No, you don't want the lock to be acquired at this point. All the other code
assumes it is acquired right when you enter the proxy. E.g., when a message
comes in to PluginDispatcher, or if you PostTask, you wrap the task in
RunWhileLocked (which locks around the Closure). This will probably break other
tests that use RunMessageLoop; probably with a deadlock error (i.e., trying to
lock from the same thread that holds the lock already). We need to instead
figure out why the printing code isn't locking and fix it there.

[dmichael (off chromium), 2012/11/06 03:12:19]

I've looked around a little, and it hasn't jumped out at me where we might be
failing to acquire the lock. But I don't understand the new resource stuff yet.
Are those messages coming in on a different channel and so not passing through
PluginDispatcher::OnMessageReceived, where we acquire the lock?

Also...  it looks like ppp_printing_proxy is not done. The calls to ppp_printing
need to be wrapped with CallWhileUnlocked.

That test must not have existed the last time I ran all these and fixed stuff
up, or something; I had all the ppapi_tests running a while back. It's also
likely that interfaces which don't have tests will have some similar problems.
But they're easy to fix once we find them.

   MessageLoop::current()->Run();
 }
 
 void QuitMessageLoop(PP_Instance instance) {
   // TODO(dmichael): We should probably assert that this is the main thread.
   MessageLoop::current()->QuitNow();
 }
 
 uint32_t GetLiveObjectsForInstance(PP_Instance instance_id) {
   ProxyAutoLock lock;
@@ skipping 127 matching lines @@
     PP_Instance instance,
     const InputEventData& input_event) {
   scoped_refptr<PPB_InputEvent_Shared> input_event_impl(
       new PPB_InputEvent_Shared(OBJECT_IS_PROXY, instance, input_event));
   ppb_testing_impl_->SimulateInputEvent(instance,
                                         input_event_impl->pp_resource());
 }
 
 }  // namespace proxy
 }  // namespace ppapi