Add a mojo ServiceRegistry to embedded workers.

content/renderer/service_worker/service_worker_context_client.h

 // 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_RENDERER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CLIENT_H_
 #define CONTENT_RENDERER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CLIENT_H_
 
 #include <map>
 #include <string>
 #include <vector>
 
 #include "base/id_map.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_ptr.h"
 #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"
 #include "third_party/WebKit/public/platform/WebMessagePortChannel.h"
 #include "third_party/WebKit/public/platform/WebServiceWorkerError.h"
 #include "third_party/WebKit/public/web/WebServiceWorkerContextClient.h"
 
 namespace base {
 class SingleThreadTaskRunner;
 class TaskRunner;
@@ skipping 36 matching lines @@
                              int64 service_worker_version_id,
                              const GURL& service_worker_scope,
                              const GURL& script_url,
                              int worker_devtools_agent_route_id);
   ~ServiceWorkerContextClient() override;
 
   void OnMessageReceived(int thread_id,
                          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&,
                           blink::WebServiceWorkerClientsCallbacks*);
   virtual void openWindow(const blink::WebURL&,
                           blink::WebServiceWorkerClientCallbacks*);
   virtual void setCachedMetadata(const blink::WebURL&,
                                  const char* data,
                                  size_t size);
   virtual void clearCachedMetadata(const blink::WebURL&);
@@ skipping 128 matching lines @@
 
   // Used for incoming messages from the browser for which an outgoing response
   // back to the browser is expected, the id must be sent back with the
   // response.
   int current_request_id_;
 
   // Initialized on the worker thread in workerContextStarted and
   // 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);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_RENDERER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CLIENT_H_