Teach EmbeddedWorkerInstance to create a process when it needs one.

content/browser/service_worker/service_worker_process_manager.h

Index: content/browser/service_worker/service_worker_process_manager.h
diff --git a/content/browser/service_worker/service_worker_process_manager.h b/content/browser/service_worker/service_worker_process_manager.h
new file mode 100644
index 0000000000000000000000000000000000000000..397aadf3e75777bb0b258f15f4cbf1b87e9bc080
--- /dev/null
+++ b/content/browser/service_worker/service_worker_process_manager.h
@@ -0,0 +1,80 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_PROCESS_MANAGER_H_
+#define CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_PROCESS_MANAGER_H_
+
+#include <vector>
+
+#include "base/callback.h"
+#include "base/memory/scoped_ptr.h"
+#include "base/memory/weak_ptr.h"
+#include "content/common/service_worker/service_worker_status_code.h"
+
+class GURL;
+
+namespace content {
+
+class BrowserContext;
+class ServiceWorkerContextWrapper;
+
+// Interacts with the UI thread to keep RenderProcessHosts alive while the
+// ServiceWorker system is using them.

[kinuko, 2014/04/28 06:58:16]

Can you also add a comment to note that an instance of this always outlives
ServiceWorkerContextCore (though we have a similar comment at ctor) and is
destructed on UI thread?

[Jeffrey Yasskin, 2014/04/28 20:47:40]

Done.

+class CONTENT_EXPORT ServiceWorkerProcessManager {
+ public:
+  // |*this| must be scoped inside |context|. |increment_for_test| and

[kinuko, 2014/04/28 06:58:16]

nit: |context| is a bit unclear in this context, |context_wrapper|->context() ?

[Jeffrey Yasskin, 2014/04/28 20:47:40]

Whoops. That comment must be from when the ProcessManager just took a
BrowserContext.

+  // ||decrement_for_test| define how to look up a process by ID and increment
+  // |or decrement its worker reference count.
+  ServiceWorkerProcessManager(
+      ServiceWorkerContextWrapper* context_wrapper,
+      const base::Callback<bool(int)>& increment_for_test =
+          base::Callback<bool(int)>(),
+      const base::Callback<bool(int)>& decrement_for_test =
+          base::Callback<bool(int)>());

[kinuko, 2014/04/28 06:58:16]

In chromium we don't use optional parameters.. could we have a separate
test-only method to override these?

[Jeffrey Yasskin, 2014/04/28 20:47:40]

Done. Note that this makes it more complicated to specify how the fields are
accessed in a thread-safe way.

+
+  ~ServiceWorkerProcessManager();
+
+  // Returns a reference to a running process suitable for starting the Service
+  // Worker at |script_url|. Processes in |process_ids| will be checked in order
+  // for existence, and if none exist, then a new process will be created. Posts
+  // |callback| to the IO thread to indicate whether creation succeeded and the
+  // process ID that has a new reference.
+  //
+  // Allocation can fail with SERVICE_WORKER_ERROR_START_WORKER_FAILED if
+  // RenderProcessHost::Init fails.
+  void AllocateWorkerProcess(
+      const std::vector<int>& process_ids,
+      const GURL& script_url,
+      const base::Callback<void(ServiceWorkerStatusCode, int process_id)>&
+          callback) const;
+
+  // Drops a reference to a process that was running a Service Worker.  This
+  // must match a call to AllocateWorkerProcess.
+  void ReleaseWorkerProcess(int process_id);
+
+ private:
+  bool IncrementWorkerRefcountByPid(int process_id) const;
+  bool DecrementWorkerRefcountByPid(int process_id) const;
+
+  // These fields are only accessed on the UI thread after construction.
+  scoped_refptr<ServiceWorkerContextWrapper> context_wrapper_;
+  base::Callback<bool(int)> increment_for_test_;
+  base::Callback<bool(int)> decrement_for_test_;
+
+  // Used to double-check that we don't access *this after it's destroyed.
+  base::WeakPtrFactory<ServiceWorkerProcessManager> weak_this_factory_;
+  base::WeakPtr<ServiceWorkerProcessManager> weak_this_;
+};
+
+}  // namespace content
+
+namespace base {
+// Specialized to post the deletion to the UI thread.
+template <>
+struct CONTENT_EXPORT DefaultDeleter<content::ServiceWorkerProcessManager> {
+  void operator()(content::ServiceWorkerProcessManager* ptr) const;

[kinuko, 2014/04/28 06:58:16]

Aha, I'd just call DeleteSoon(BrowserThread::UI, FROM_HERE,
process_manager_.release()) in context core's dtor, but well this'd work too and
might be more explicit.

[Jeffrey Yasskin, 2014/04/28 20:47:40]

I was nervous about using a scoped_ptr that didn't actually include the
instructions for how to destroy its contents. It kind of breaks the contract for
scoped_ptr.

I considered beefing up BrowserThread::DeleteOnThread<UI> to work as a
scoped_ptr deleter, but then I realized that would make the code that creates
ProcessManagers significantly more verbose. Since we have the pattern that
refcounted objects can explicitly state the thread they get destroyed on, and
the definition of this class assumes that it's destroyed on UI, overriding the
default deleter seems like the right way to enforce that.

[kinuko, 2014/04/29 01:06:52]

Yep, I can see some benefits here.

+};
+}  // namespace base
+
+#endif  // CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_PROCESS_MANAGER_H_