[Chromoting] Introducing refcount-based life time management of the message loops in the service (d…

remoting/host/plugin/host_script_object.cc

Index: remoting/host/plugin/host_script_object.cc
diff --git a/remoting/host/plugin/host_script_object.cc b/remoting/host/plugin/host_script_object.cc
index 1f83dcde3c6b5cac3e911324757c444b62f31c6a..129c126b162b26f6a8a85143f44e6d053d5a323b 100644
--- a/remoting/host/plugin/host_script_object.cc
+++ b/remoting/host/plugin/host_script_object.cc
@@ -16,6 +16,7 @@
 #include "base/values.h"
 #include "net/base/net_util.h"
 #include "remoting/base/auth_token_util.h"
+#include "remoting/base/auto_message_loop.h"
 #include "remoting/host/chromoting_host.h"
 #include "remoting/host/chromoting_host_context.h"
 #include "remoting/host/desktop_environment.h"
@@ -121,9 +122,7 @@ HostNPScriptObject::~HostNPScriptObject() {
     // here because |host_context_| needs to be stopped on the plugin
     // thread, but the plugin thread may not exist after the instance
     // is destroyed.
-    disconnected_event_.Reset();
     DisconnectInternal();
-    disconnected_event_.Wait();
 
     // UI needs to be shut down on the UI thread before we destroy the
     // host context (because it depends on the context object), but
@@ -134,6 +133,10 @@ HostNPScriptObject::~HostNPScriptObject() {
 
     // Stops all threads.
     host_context_.reset();
+
+    // |disconnected_event_| is signalled when the last reference to the plugin
+    // thread is dropped.
+    disconnected_event_.Wait();

[Wez, 2012/08/28 17:34:53]

Since is blocked on this event, the plugin thread isn't available to process
tasks at this point, so you can just block waiting on the Threads in
|host_context_| exiting, rather than keep a separate event.

[alexeypa (please no reviews), 2012/08/28 19:18:51]

Waiting on the event does more than waiting for the threads to stop. It also
makes sure that all objects referencing the main loop where also destroyed. An
example is |desktop_environment_| that should be destroyed because it keeps
references to the main loop.

[Wez, 2012/08/30 18:20:12]

As discussed offline, we don't currently have the capability to continue pumping
messages posted to the main/plugin thread's task runner once we've been asked to
shutdown, so waiting for objects that references the plugin TaskRunner to drop
those references isn't valid; instead we should either drop posted tasks or use
an AutoThreadTaskRunner just to CHECK for tasks being posted after we've stopped
processing them?

[Wez, 2012/08/30 18:25:40]

Actually the plugin TaskRunner won't even return false at this point, will it,
in which case wrapping it to get CHECKs won't do anything.

[alexeypa (please no reviews), 2012/08/30 22:08:07]

I added a comment before "plugin_task_runner_->Detach();".

[alexeypa (please no reviews), 2012/08/30 22:08:07]

PluginThreadTaskRunner returns false during shutdown.

   }
 
   worker_thread_.Stop();
@@ -143,7 +146,10 @@ bool HostNPScriptObject::Init() {
   DCHECK(plugin_task_runner_->BelongsToCurrentThread());
   VLOG(2) << "Init";
 
-  host_context_.reset(new ChromotingHostContext(plugin_task_runner_));
+  host_context_.reset(new ChromotingHostContext(new AutoMessageLoop(
+      NULL, plugin_task_runner_,
+      base::Bind(&base::WaitableEvent::Signal,
+                 base::Unretained(&disconnected_event_)))));
   if (!host_context_->Start()) {
     host_context_.reset();
     return false;
@@ -871,13 +877,12 @@ void HostNPScriptObject::DisconnectInternal() {
 
   switch (state_) {
     case kDisconnected:
-      disconnected_event_.Signal();
       return;
 
     case kStarting:
+      desktop_environment_.reset();
       SetState(kDisconnecting);
       SetState(kDisconnected);
-      disconnected_event_.Signal();
       return;
 
     case kDisconnecting:
@@ -906,7 +911,7 @@ void HostNPScriptObject::DisconnectInternal() {
 void HostNPScriptObject::OnShutdownFinished() {
   DCHECK(host_context_->network_task_runner()->BelongsToCurrentThread());
 
-  disconnected_event_.Signal();
+  desktop_environment_.reset();

[Wez, 2012/08/28 17:34:53]

Is this from a DesktopEnvironment->DesktopEnvironmentFactory CL?

[alexeypa (please no reviews), 2012/08/28 19:18:51]

No, it references the main message loop, so it has to be destroyed.

 }
 
 void HostNPScriptObject::OnPolicyUpdate(