Make Mandoline shut down cleanly.

mojo/application/app_lifetime_helper.cc

Index: mojo/application/app_lifetime_helper.cc
diff --git a/mojo/application/app_lifetime_helper.cc b/mojo/application/app_lifetime_helper.cc
new file mode 100644
index 0000000000000000000000000000000000000000..bce4738a47aafe9fb978c3c3e1f0ee2d81750261
--- /dev/null
+++ b/mojo/application/app_lifetime_helper.cc
@@ -0,0 +1,68 @@
+// 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 "mojo/application/app_lifetime_helper.h"
+
+#include "base/bind.h"
+#include "base/message_loop/message_loop.h"
+#include "mojo/application/public/cpp/application_impl.h"
+
+namespace mojo {
+
+AppRefCount::AppRefCount(
+    AppLifetimeHelper* app_lifetime_helper,
+    scoped_refptr<base::SingleThreadTaskRunner> app_task_runner)
+    : app_lifetime_helper_(app_lifetime_helper),
+      app_task_runner_(app_task_runner) {
+}
+
+AppRefCount::~AppRefCount() {
+  if (app_task_runner_->BelongsToCurrentThread()) {
+    app_lifetime_helper_->Release();
+    return;
+  }
+
+  app_task_runner_->PostTask(
+      FROM_HERE,
+      base::Bind(&AppLifetimeHelper::Release,
+                 base::Unretained(app_lifetime_helper_)));
+}
+
+scoped_ptr<AppRefCount> AppRefCount::Clone() {
+  if (app_task_runner_->BelongsToCurrentThread()) {
+    app_lifetime_helper_->AddRef();
+  } else {
+    app_task_runner_->PostTask(
+        FROM_HERE,
+        base::Bind(&AppLifetimeHelper::AddRef,

[yzshen1, 2015/05/15 06:56:12]

Is it possible to have races because of this AddRef delay? For example,

=================
Thread-1: (the thread on which AppLifetimeHelper lives)
...
condition_var.Wait();
app_ref_count_1.reset();
...
=================
Thread-2:
...
app_ref_count_2 = app_ref_count_1.Clone();
condition_var.Signal();
...
=================

If |app_ref_count_1| is the only ref count before |app_ref_count_2| is created,
then it seems possible that the application is terminated before AddRef for
|app_ref_count_2| executes.

One idea is to make AppRefCount a RefCountedThreadSafe object, services hold on
to scoped_refptr<AppRefCount>. In ~AppRefCount(), a task is posted to the
application thread to do Terminate.

What do you think? Thanks!

[jam, 2015/05/15 07:08:44]

I had thought about this, but I convinced myself that it's not a problem. Feel
free to poke holes through this logic:

I thought that if thread-2 is doing a Clone, then that means that thread 2 is
where a service is living. That means that thread 2 will be the one that
releases the object on which Clone is called on. So when that is released, it
will post task the Release, which will be behind the AddRef.

+                   base::Unretained(app_lifetime_helper_)));
+  }
+
+  return make_scoped_ptr(new AppRefCount(
+      app_lifetime_helper_, app_task_runner_));
+}
+
+AppLifetimeHelper::AppLifetimeHelper()
+    : ref_count_(0) {
+}
+
+AppLifetimeHelper::~AppLifetimeHelper() {
+}
+
+scoped_ptr<AppRefCount> AppLifetimeHelper::CreateAppRefCount() {
+  AddRef();
+  return make_scoped_ptr(new AppRefCount(
+      this, base::MessageLoop::current()->task_runner()));
+}
+
+void AppLifetimeHelper::AddRef() {
+  ref_count_++;
+}
+
+void AppLifetimeHelper::Release() {
+  if (!--ref_count_)
+    ApplicationImpl::Terminate();
+}
+
+}  // namespace mojo