BackgroundSyncManager tracks client registrations

content/child/background_sync/background_sync_provider_thread_proxy.cc

Index: content/child/background_sync/background_sync_provider_thread_proxy.cc
diff --git a/content/child/background_sync/background_sync_provider_thread_proxy.cc b/content/child/background_sync/background_sync_provider_thread_proxy.cc
index 97466b23bf18dc84ee0787d8d4c817ea9fda156a..ace2ab2564a35e88f23ae66e6df94f968328675f 100644
--- a/content/child/background_sync/background_sync_provider_thread_proxy.cc
+++ b/content/child/background_sync/background_sync_provider_thread_proxy.cc
@@ -176,6 +176,19 @@ void BackgroundSyncProviderThreadProxy::getPermissionStatus(
                      WorkerTaskRunner::Instance()->CurrentWorkerId())));
 }
 
+void BackgroundSyncProviderThreadProxy::trackRegistration(

[michaeln, 2015/08/21 02:39:25]

adoptRegistrationHandle(handle_id)

[jkarlin, 2015/08/25 17:32:58]

Changed to "GetRegistrationForHandleId" as it now asks the service to create a
new handle and return the corresponding mojo registration.

+    blink::WebSyncRegistration* registration) {
+  main_thread_task_runner_->PostTask(
+      FROM_HERE, base::Bind(&BackgroundSyncProvider::trackRegistration,
+                            base::Unretained(sync_provider_), registration));

[michaeln, 2015/08/21 02:39:25]

it'd be good to indicate xfer of ownership of |registration| with a
make_scoped_ptr here... but WebSyncRegistration aren't threadsafe so you'll have
to do something else here.


Bah... also, I'm noticing that the messaging is all being routed to thru the
main thread. That will wreak havok on the lifetime management scheme i described
because that scheme depends on the relative ordering of trackRegistrationMojoMsg
and didHandleSyncEventMojoMsg. If they come out of order it doesn't work and
routing the the track traffic thru a mojo intf on main thread vs the
handledEvent traffic thru an intf directly on the worker thread pretty much
guarantees they'll show up in the wrong order :(

[jkarlin, 2015/08/25 17:32:58]

OBE. The new method takes a HandleId.
With my current implementation the manager has handle that is kept until the
event finishes. While the event is firing the client requests a duplicate handle
for the same id. didHandleSyncEventMojoMsg won't come before the request for the
duplicate handle as the event won't be completed until the duplicate handle has
been returned.

+}
+
+void BackgroundSyncProviderThreadProxy::releaseRegistration(int64_t sync_id) {

[michaeln, 2015/08/21 02:39:25]

releaseRegistrationHandle(handle_id)

[jkarlin, 2015/08/25 17:32:58]

Changed sync_id to handle_id. Added a TODO to update the function names later
(it requires a 3-legged patch due to a change to WebSyncProvider.h)

+  main_thread_task_runner_->PostTask(
+      FROM_HERE, base::Bind(&BackgroundSyncProvider::releaseRegistration,
+                            base::Unretained(sync_provider_), sync_id));
+}
+
 void BackgroundSyncProviderThreadProxy::OnWorkerRunLoopStopped() {
   delete this;
 }