Wire provider_id into scriptable API provider to start listening events

content/browser/service_worker/service_worker_provider_host.h

 // Copyright 2013 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_PROVIDER_HOST_H_
 #define CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_PROVIDER_HOST_H_
 
+#include <set>
+
 #include "base/memory/ref_counted.h"
 #include "base/memory/weak_ptr.h"
 #include "webkit/common/resource_type.h"
 
 namespace content {
 
 class ServiceWorkerVersion;
 
 // This class is the browser-process representation of a serice worker
 // provider. There is a provider per document and the lifetime of this
 // object is tied to the lifetime of its document in the renderer process.
 // This class holds service worker state this is scoped to an individual
 // document.
 class ServiceWorkerProviderHost
     : public base::SupportsWeakPtr<ServiceWorkerProviderHost> {
  public:
   ServiceWorkerProviderHost(int process_id,
                             int provider_id);
   ~ServiceWorkerProviderHost();
 
   int process_id() const { return process_id_; }
   int provider_id() const { return provider_id_; }
 
+  // Adds and removes client thread ID, who is listening events dispatched
+  // from ServiceWorker to the document corresponding to this provider.

[michaeln, 2014/03/07 01:33:58]

This comment could be massaged to mention the document and any of its dedicated
workers that may be listening for SW related events.

[kinuko, 2014/03/07 02:02:17]

Done.

+  void AddScriptClient(int thread_id);
+  void RemoveScriptClient(int thread_id);
+
   // The service worker version that corresponds with navigator.serviceWorker
   // for our document.
   ServiceWorkerVersion* associated_version() const {
     return  associated_version_.get();
   }
 
+  const std::set<int>& client_thread_ids() const { return client_thread_ids_; }

[michaeln, 2014/03/06 20:24:29]

Shouldn't there only be one script client thread? This corresponds to the
WebCore context thread on which a Document/Worker is running and there is only
one of those.

I can see how we might get multiple instances of WebServiceWorkerProviderImpl
(depending), but they'll all be on the same "apartment thread" so to speak.

If that's not right, can you explain how we'll see multiple thread_ids here.

[kinuko, 2014/03/07 00:22:23]

In the CL the Add/Remove messages are sent from thread-specific dispatcher that
is created by WebServiceWorkerProviderImpl, and browser can directly send
messages to those script providers from the browser (where we can use these
thread IDs), that is my assumption.  If I rename this 'client' to 'script
provider threads' or something else will that become clearer, or probably you're
assuming different model?

+
   // Returns true if this provider host should handle requests for
   // |resource_type|.
   bool ShouldHandleRequest(ResourceType::Type resource_type) const;
 
  private:
   const int process_id_;
   const int provider_id_;
+  std::set<int> client_thread_ids_;
   scoped_refptr<ServiceWorkerVersion> associated_version_;
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_PROVIDER_HOST_H_