BackgroundSyncManager tracks client registrations

content/child/background_sync/background_sync_provider_thread_proxy.cc

 // 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.
 
 #include "content/child/background_sync/background_sync_provider_thread_proxy.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/lazy_instance.h"
 #include "base/location.h"
@@ skipping 158 matching lines @@
       FROM_HERE,
       base::Bind(&BackgroundSyncProvider::getPermissionStatus,
                  base::Unretained(sync_provider_), periodicity,
                  service_worker_registration,
                  new CallbackThreadAdapter<blink::WebSyncPermissionStatus*,
                                            blink::WebSyncError*>(
                      make_scoped_ptr(callbacks),
                      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;
 }
 
 BackgroundSyncProviderThreadProxy::BackgroundSyncProviderThreadProxy(
     base::SingleThreadTaskRunner* main_thread_task_runner,
     BackgroundSyncProvider* sync_provider)
     : main_thread_task_runner_(main_thread_task_runner),
       sync_provider_(sync_provider) {
   g_sync_provider_tls.Pointer()->Set(this);
 }
 
 BackgroundSyncProviderThreadProxy::~BackgroundSyncProviderThreadProxy() {
   g_sync_provider_tls.Pointer()->Set(nullptr);
 }
 
 }  // namespace content