Enable pepper threading by default.

ppapi/proxy/ppb_testing_proxy.cc

Index: ppapi/proxy/ppb_testing_proxy.cc
diff --git a/ppapi/proxy/ppb_testing_proxy.cc b/ppapi/proxy/ppb_testing_proxy.cc
index b8c9ce07d3afb86a866fe26d4ccd89448197d25b..ffcb3e46b203c1dde1d878e84709284acca713c5 100644
--- a/ppapi/proxy/ppb_testing_proxy.cc
+++ b/ppapi/proxy/ppb_testing_proxy.cc
@@ -54,6 +54,7 @@ PP_Bool ReadImageData(PP_Resource graphics_2d,
 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();
 }