BackgroundSyncManager tracks client registrations

content/child/background_sync/background_sync_provider_thread_proxy.h

 // Copyright 2015 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_CHILD_BACKGROUND_SYNC_BACKGROUND_SYNC_PROVIDER_THREAD_PROXY_H_
 #define CONTENT_CHILD_BACKGROUND_SYNC_BACKGROUND_SYNC_PROVIDER_THREAD_PROXY_H_
 
 #include "base/macros.h"
 #include "content/child/worker_task_runner.h"
+#include "content/common/background_sync_service.mojom.h"
 #include "third_party/WebKit/public/platform/modules/background_sync/WebSyncProvider.h"
 
 namespace base {
 class SingleThreadTaskRunner;
 }
 
 namespace content {
 
 class BackgroundSyncProvider;
 
 // BackgroundSyncProviderThreadProxy is a proxy to the BackgroundSyncProvider
 // for callers running on a different thread than the main thread. There is one
 // instance per worker thread.
 //
 // This class handles all of the thread switching, jumping to the main thread to
 // call the WebSyncProvider methods, and wrapping the callbacks passed in with
 // code to switch back to the original calling thread.
 class BackgroundSyncProviderThreadProxy : public blink::WebSyncProvider,

[michaeln, 2015/08/28 02:53:11]

I don't think we're taking full advantage of mojo with the current design
pattern.

Mojo ipc gives us lightweight interface ptrs which can be bound to any thread so
we can avoid doing heavyweight manual thread hopping. The lifetimes of the
objects on either side can be scoped to one another which can be help with
resource reclamation when things unwind.

What if instead of a 'proxy' each thread had its own BackgroundSyncProvider
instance with its own BackgroundSyncServicePtr interface ptr?

[iclelland, 2015/08/28 12:55:21]

That's actually a good idea -- I wrote the original thread proxy, with the
intention of having just one mojo channel from each renderer to the browser.
Since the mojo interfaces are so light, though, and since mojo is going to do a
thread hop to its own UI thread regardless of where we call it from (as I
understand it,) then it makes sense to try to avoid doing another one here, at
the expense of a mojo connection per thread.

Can that refactoring be in a separate CL, or would you want to see it in this
one? 

[jkarlin, 2015/09/02 23:51:41]

Agree that this should be done. Also agree it's for another CL.  Created bug
https://code.google.com/p/chromium/issues/detail?id=527601

                                           public WorkerTaskRunner::Observer {
  public:
   static BackgroundSyncProviderThreadProxy* GetThreadInstance(
       base::SingleThreadTaskRunner* main_thread_task_runner,
       BackgroundSyncProvider* permissions_dispatcher);
 
   // blink::WebSyncProvider implementation
   void registerBackgroundSync(
       const blink::WebSyncRegistration* options,
       blink::WebServiceWorkerRegistration* service_worker_registration,
       blink::WebSyncRegistrationCallbacks* callbacks);
   void unregisterBackgroundSync(
       blink::WebSyncRegistration::Periodicity periodicity,
       int64_t id,

[michaeln, 2015/08/28 02:53:11]

is this an int handle_id and are the other inputs needed?

Might be out of scope but would it make sense to pass a WebSyncRegistration*
here instead of passing an id value. If i understand the api properly, the
caller receives that data type in response to the regiseter and get methods. I
think it contains the handle_id value of interest.
(similar to how WebServiceWorkerRegistration is not referred to by id in the
WebKit api)

[jkarlin, 2015/09/02 23:51:41]

Needs to be done in a follow-up cl. TODO added.
Ack. I'm torn on this, since the only thing that's needed is the id and passing
less is often better. 

       const blink::WebString& tag,
       blink::WebServiceWorkerRegistration* service_worker_registration,
       blink::WebSyncUnregistrationCallbacks* callbacks);
   void getRegistration(
       blink::WebSyncRegistration::Periodicity,
       const blink::WebString& tag,
       blink::WebServiceWorkerRegistration* service_worker_registration,
       blink::WebSyncRegistrationCallbacks* callbacks);
   void getRegistrations(
       blink::WebSyncRegistration::Periodicity periodicity,
       blink::WebServiceWorkerRegistration* service_worker_registration,
       blink::WebSyncGetRegistrationsCallbacks* callbacks);
   void getPermissionStatus(
       blink::WebSyncRegistration::Periodicity periodicity,
       blink::WebServiceWorkerRegistration* service_worker_registration,
       blink::WebSyncGetPermissionStatusCallbacks* callbacks);
+  // TODO(jkarlin): Rename to releaseRegistrationHandle.
+  void releaseRegistration(int64_t handle_id);
+
+  // Given |handle_id|, ask the provider for a new handle with the same
+  // underlying registration.
+  void DuplicateRegistrationHandle(
+      int64 handle_id,
+      int64 service_worker_registration_id,
+      const BackgroundSyncService::DuplicateRegistrationHandleCallback&
+          callback);
 
   // WorkerTaskRunner::Observer implementation.
   void OnWorkerRunLoopStopped() override;
 
  private:
   BackgroundSyncProviderThreadProxy(
       base::SingleThreadTaskRunner* main_thread_task_runner,
       BackgroundSyncProvider* sync_provider);
 
   virtual ~BackgroundSyncProviderThreadProxy();
 
   scoped_refptr<base::SingleThreadTaskRunner> main_thread_task_runner_;
 
   // This belongs to the renderer main thread, (created by BlinkPlatformImpl)
   // and so should outlive the BackgroundSyncProviderThreadProxy, which is
   // created for a worker thread.
   BackgroundSyncProvider* sync_provider_;
 
   DISALLOW_COPY_AND_ASSIGN(BackgroundSyncProviderThreadProxy);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_CHILD_BACKGROUND_SYNC_BACKGROUND_SYNC_PROVIDER_THREAD_PROXY_H_