Have each SandboxedProcessLauncherDelegate maintain a zygote.

components/nacl/browser/nacl_process_host.cc

Index: components/nacl/browser/nacl_process_host.cc
diff --git a/components/nacl/browser/nacl_process_host.cc b/components/nacl/browser/nacl_process_host.cc
index 41e337a408bb0fd76fb89ad7381449f100fd71f6..75ab51ca52ebe7a0b7e01a3d7f49782ffe5aeefe 100644
--- a/components/nacl/browser/nacl_process_host.cc
+++ b/components/nacl/browser/nacl_process_host.cc
@@ -181,7 +181,13 @@ class NaClSandboxedProcessLauncherDelegate
     }
   }
 #elif defined(OS_POSIX)
-  bool ShouldUseZygote() override { return true; }
+#if !defined(OS_MACOSX) && !defined(OS_ANDROID)
+  content::ZygoteHandle* GetZygote() override {
+    static content::ZygoteHandle zygote;

[Mark Seaborn, 2016/01/11 22:42:39]

Does this mean the zygote process is launched on demand?  Doesn't that break
auto-update via Linux package managers (as described in
http://neugierig.org/software/chromium/notes/2011/08/zygote.html)?

[mdempsky, 2016/01/11 22:50:28]

Yes.  I'm not convinced that's a problem per se (see below), but perhaps we
should try to launch all of the zygote processes at startup for now, and change
to on-demand for non-critical zygotes in a separate CL.
It does.  However, at least my anecdotal experience with Chrome on Linux in
recent history is that we don't handle Chrome being updated on disk underneath
us very gracefully anyway.  Whenever the hot-dog-update icon appears for me,
Chrome becomes super laggy and crashy anyway, and I *have* to reboot to get even
basic things like Gmail and YouTube usable again.

+    return &zygote;
+  }
+#endif  // !defined(OS_MACOSX) && !defined(OS_ANDROID)
+
   base::ScopedFD TakeIpcFd() override { return std::move(ipc_fd_); }
 #endif  // OS_WIN