Don't shutdown render "process" in single process mode

content/browser/renderer_host/render_process_host_impl.cc

Index: content/browser/renderer_host/render_process_host_impl.cc
diff --git a/content/browser/renderer_host/render_process_host_impl.cc b/content/browser/renderer_host/render_process_host_impl.cc
index 1b610a259edac5a9f2708f3ca05886726453ce95..00c75989f27460ef91f6d4b578c60e9c7966f5f8 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -357,6 +357,7 @@ RenderProcessHostImpl::RenderProcessHostImpl(
 }
 
 RenderProcessHostImpl::~RenderProcessHostImpl() {
+  DCHECK(!run_renderer_in_process());
   ChildProcessSecurityPolicyImpl::GetInstance()->Remove(GetID());
 
   // We may have some unsent messages at this point, but that's OK.
@@ -366,13 +367,6 @@ RenderProcessHostImpl::~RenderProcessHostImpl() {
     queued_messages_.pop();
   }
 
-  if (run_renderer_in_process()) {
-    // In single process mode, need to set IO allowed in browser main thread
-    // before joining the renderer thread
-    base::ThreadRestrictions::ScopedAllowIO allow_io;
-    in_process_renderer_.reset();
-  }
-
   ClearTransportDIBCache();
   UnregisterHost(GetID());
 }
@@ -876,7 +870,7 @@ base::ProcessHandle RenderProcessHostImpl::GetHandle() {
 
 bool RenderProcessHostImpl::FastShutdownIfPossible() {
   if (run_renderer_in_process())
-    return false;  // Single process mode can't do fast shutdown.
+    return false;  // Single process mode never shutdown the renderer.
 
   if (!GetContentClient()->browser()->IsFastShutdownPossible())
     return false;
@@ -1133,7 +1127,9 @@ void RenderProcessHostImpl::Release(int routing_id) {
     return;
   }
 #endif
-  Cleanup();
+  // Keep the one renderer thread around forever in single process mode.

[Jeffrey Yasskin, 2012/12/14 22:10:51]

I'm now seeing a DCHECK-failure when running `xvfb-run out/Debug/browser_tests
--single-process --gtest_filter=DeclarativeApiTest.DeclarativeApi` at
chrome/browser/profiles/profile_destroyer.cc:40: "DCHECK(hosts.empty() ||
profile->IsOffTheRecord());" It showed up about the time this CL was committed,
but I haven't rolled back to be sure. Any suggestions for how to fix it?

[joth, 2012/12/14 22:34:12]

Good question. Most of the logic in the DestroyProfileWhenAppropriate() function
is incorrect for single process mode, as single process does not support off the
record. (It cannot: it only supports one profile as there's only one renderer).
Also 'render' process shutdown was never reliable in single process mode (it was
race prone). The simplest 'solution' (?) maybe to add "if
(CommandLine::HasSwitch(kSingleProcess)) return;" prior to that DCHECK. (i.e.
leak the profile too when running in unsupported mdoe) .. I haven't tried that
though, maybe something else will break...

+  if (!run_renderer_in_process())
+    Cleanup();
 }
 
 void RenderProcessHostImpl::Cleanup() {
@@ -1486,8 +1482,9 @@ int RenderProcessHostImpl::GetActiveViewCount() {
 void RenderProcessHostImpl::OnShutdownRequest() {
   // Don't shut down if there are more active RenderViews than the one asking
   // to close, or if there are pending RenderViews being swapped back in.
+  // In single process mode, we never shutdown the renderer.
   int num_active_views = GetActiveViewCount();
-  if (pending_views_ || num_active_views > 1)
+  if (pending_views_ || num_active_views > 1 || run_renderer_in_process())

[joth, 2012/11/29 23:00:24]

I did consider doing this check in render process instead, but
ChildThread::OnProcessFinalRelease specifically comments the protocol is to
always defer to the host (browser) opinion on this, and also, at this point we
only want to alter the renderer behavior not all possible child processes.

     return;
 
   // Notify any contents that might have swapped out renderers from this