Clear SingleProcess and InProcessGPU logic.

content/app/content_main_runner.cc

Index: content/app/content_main_runner.cc
diff --git a/content/app/content_main_runner.cc b/content/app/content_main_runner.cc
index da27afaaf017aa36d9ca79c77b98cbf032ac72f3..b09ff031a32afd28672c2395e00c834347abe5b2 100644
--- a/content/app/content_main_runner.cc
+++ b/content/app/content_main_runner.cc
@@ -437,6 +437,11 @@ int RunNamedProcessTypeMain(
       CreateInProcessRendererThread);
   GpuProcessHost::RegisterGpuMainThreadFactory(
       CreateInProcessGpuThread);
+#else
+  // SingleProcess and InProcessGPU mode are not supported
+  // in multiple-dll mode currently.
+  CHECK(!(command_line.HasSwitch(switches::kSingleProcess) ||
+      command_line.HasSwitch(switches::kInProcessGPU)));

[piman, 2013/11/07 22:09:52]

I suspect some people currently use that. What's broken exactly?

[dshwang, 2013/11/08 10:05:56]

under defined(CHROME_MULTIPLE_DLL_BROWSER), we don't register InProcessGPU
thread constructor, CreateInProcessGpuThread, so we must not use
--in-process-gpu.

We launch GPU process if InProcessGPU thread constructor is not set although
--in-process-gpu.
if (in_process_ && g_gpu_main_thread_factory) {
  in_process_gpu_thread_->Start();
} else if (!LaunchGpuProcess(channel_id)) {
  return false;
}

However, we don't check g_gpu_main_thread_factory in other InProcessGPU code.
e.g. gpu process termination code
It can cause a bad bug.

Utility and Render process has the same issue to gpu process.

 #endif
 
   for (size_t i = 0; i < arraysize(kMainFunctions); ++i) {