Change the GPU process to use a CFRunLoop

content/gpu/gpu_main.cc

Index: content/gpu/gpu_main.cc
diff --git a/content/gpu/gpu_main.cc b/content/gpu/gpu_main.cc
index 0dac81d459486c2f04a8a862b9afedc92e47e284..37309affa509fc80c4ced87a41776d70721cfcc6 100644
--- a/content/gpu/gpu_main.cc
+++ b/content/gpu/gpu_main.cc
@@ -51,6 +51,10 @@
 #include "content/public/common/sandbox_init.h"
 #endif
 
+#if defined(OS_MACOSX)
+#include "base/message_loop/message_pump_mac.h"
+#endif
+
 const int kGpuTimeout = 10000;
 
 namespace content {
@@ -129,8 +133,8 @@ int GpuMain(const MainFunctionParams& parameters) {
   // GpuMsg_Initialize message from the browser.
   bool dead_on_arrival = false;
 
-  base::MessageLoop::Type message_loop_type = base::MessageLoop::TYPE_IO;
 #if defined(OS_WIN)

[ccameron, 2014/05/12 20:06:50]

IMO the MessageLoop type enums are of limited utility, since many platforms
don't have a clear definition of what a UI loop is (see the breakdown in
https://code.google.com/p/chromium/issues/detail?id=312462#c51).

I didn't try to shoehorn another type into the enum, but rather, followed the
model in
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...

[Robert Sesek, 2014/05/12 20:11:43]

They do have limited utility, but we're starting to encounter other main-thread
non-TYPE_UI MessageLoops, which is what this is. I agree this is the right
approach.

+  base::MessageLoop::Type message_loop_type = base::MessageLoop::TYPE_IO;
   // Unless we're running on desktop GL, we don't need a UI message
   // loop, so avoid its use to work around apparent problems with some
   // third-party software.
@@ -139,11 +143,19 @@ int GpuMain(const MainFunctionParams& parameters) {
           gfx::kGLImplementationDesktopName) {
     message_loop_type = base::MessageLoop::TYPE_UI;
   }
+  base::MessageLoop main_message_loop(message_loop_type);
 #elif defined(OS_LINUX)
-  message_loop_type = base::MessageLoop::TYPE_DEFAULT;
+  base::MessageLoop main_message_loop(base::MessageLoop::TYPE_DEFAULT);
+#elif defined(OS_MACOSX)
+  // This is necessary for CoreAnimation layers hosted in the GPU process to be

[Robert Sesek, 2014/05/12 20:11:43]

Do you know what specifically requires this? I'm assuming something installs a
CFRunLoopSource that needs to get serviced, likely because the library doesn't
use its own thread for this.

[ccameron, 2014/05/12 20:30:44]

Not sure. I've verified in Chrome and in stand-alone applications. I tried
running an example application with breakpoints in CFRunLoopSourceCreate and
CFMachPortCreateRunLoopSource, and didn't hit anything.

[Robert Sesek, 2014/05/12 22:11:50]

Interesting. What about CFRunLoopAddSource?

+  // drawn. See:
+  // http://crbug.com/312462

[Robert Sesek, 2014/05/12 20:11:43]

nit: No need for this to be on its own line.

[ccameron, 2014/05/12 20:30:44]

Done.

+  scoped_ptr<base::MessagePump> pump(new base::MessagePumpCFRunLoop());
+  base::MessageLoop main_message_loop(pump.Pass());
+#else
+  base::MessageLoop main_message_loop(base::MessageLoop::TYPE_IO);
 #endif
 
-  base::MessageLoop main_message_loop(message_loop_type);
   base::PlatformThread::SetName("CrGpuMain");
 
   // In addition to disabling the watchdog if the command line switch is