Add a mojo ServiceRegistry to embedded workers.

content/renderer/service_worker/service_worker_context_client.h

Index: content/renderer/service_worker/service_worker_context_client.h
diff --git a/content/renderer/service_worker/service_worker_context_client.h b/content/renderer/service_worker/service_worker_context_client.h
index 9dfb01deb27e3e41dafceb3af3a9034a847aafe3..cbc1bac5e4c05d1a599240079f534075eef56052 100644
--- a/content/renderer/service_worker/service_worker_context_client.h
+++ b/content/renderer/service_worker/service_worker_context_client.h
@@ -15,6 +15,7 @@
 #include "base/strings/string16.h"
 #include "base/time/time.h"
 #include "content/child/webmessageportchannel_impl.h"
+#include "content/common/mojo/service_registry_impl.h"
 #include "content/common/service_worker/service_worker_types.h"
 #include "ipc/ipc_listener.h"
 #include "third_party/WebKit/public/platform/WebGeofencingEventType.h"
@@ -71,6 +72,10 @@ class ServiceWorkerContextClient
                          int embedded_worker_id,
                          const IPC::Message& message);
 
+  void BindServiceRegistry(
+      mojo::InterfaceRequest<mojo::ServiceProvider> services,
+      mojo::ServiceProviderPtr exposed_services);
+
   // WebServiceWorkerContextClient overrides.
   virtual blink::WebURL scope() const;
   virtual void getClients(const blink::WebServiceWorkerClientQueryOptions&,
@@ -219,6 +224,8 @@ class ServiceWorkerContextClient
   // destructed on the worker thread in willDestroyWorkerContext.
   scoped_ptr<WorkerContextData> context_;
 
+  ServiceRegistryImpl service_registry_;

[michaeln, 2015/07/15 21:18:52]

The ServiceWorkerContextClient is used on multiple threads. It's created deleted
on the main thread, but this registry data member will be bound and used on the
worker thread. Is it OK to delete this member on the main thread? I would expect
that it is not but don't really know.

Ah, ServiceRegistryImpl class hasa WeakPtrFactory, that all on its own has
thread affinity and shouldn't be deleted on the wrong thread.

The ServiceWorkerDispatcher class is generally a safer place to store objects
with strong thread affinity like this. The ServiceWorkerDispatcher class is
strictly single threaded (created, used, deleted exclusively on one thread) and
intentionally difficult to reach from the wrong thread.

[Marijn Kruisselbrink, 2015/07/15 21:45:58]

Hmm, yeah, that's a good point. I'm not sure if ServiceWorkerDispatcher is
necessarily a better fit in this case though. SWDispatcher currently seems to be
used just for the navigator.serviceWorker API; that is, generally the "client
side" service worker API, not for the service worker side of the API. So it
feels a bit wrong to plump through the bits necessary to actually dispatch
events (would it still be ServiceWorkerContextClient::workerContextStarted that
would actually register services with the ServiceRegistry that would then live
in SWDispatcher?).

So I'm not sure what would be more desirable; move the ServiceRegistry instance
to be part of SWDispatcher (while still initializing parts of it from
SWCC::workerContextStarted, since that's where the blink bits that are needed
are available), or keep it as owned by SWDispatcher, just making sure
ServiceRegistry isn't created until workerContextStarted is called and is
deleted by willDestroyWorkerContext.
Or maybe as a third option add a new thread-local EmbeddedWorkerSomething class,
that for now just owns this ServiceRegistry. But that just seems extra
boilerplate for no good reason.

+
   DISALLOW_COPY_AND_ASSIGN(ServiceWorkerContextClient);
 };