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

remoting/host/chromoting_host_context.h

 // Copyright (c) 2012 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 REMOTING_HOST_CHROMOTING_HOST_CONTEXT_H_
 #define REMOTING_HOST_CHROMOTING_HOST_CONTEXT_H_
 
-#include <string>
-
 #include "base/gtest_prod_util.h"
 #include "base/memory/ref_counted.h"
-#include "base/threading/platform_thread.h"
+#include "base/single_thread_task_runner.h"
 #include "base/threading/thread.h"
 
-namespace base {
-class SingleThreadTaskRunner;
-}  // namespace base
-
 namespace net {
 class URLRequestContextGetter;
 }  // namespace net
 
 namespace remoting {
 
 // A class that manages threads and running context for the chromoting host
 // process.  This class is virtual only for testing purposes (see below).
 class ChromotingHostContext {
  public:
   // Create a context.
   ChromotingHostContext(
       scoped_refptr<base::SingleThreadTaskRunner> ui_task_runner);
   virtual ~ChromotingHostContext();
 
   // TODO(ajwong): Move the Start method out of this class. Then
   // create a static factory for construction, and destruction.  We
   // should be able to remove the need for virtual functions below
   // with that design, while preserving the relative simplicity of
   // this API.
   virtual bool Start();
 
+  void Stop();

[Sergey Ulanov, 2012/08/31 01:25:18]

Seems wrong to call this method Stop() given that it doesn't really stop the
threads. Maybe FreeThreads() or UnrefThreads()?

You essentially tie the lifetime of all threads to the lifetime of the main UI
thread: i.e. we really stop these threads only after the main thread message
loop quits. Why not stop them in the same manner we quit the main thread?

[alexeypa (please no reviews), 2012/08/31 19:57:36]

Done. ReleaseTaskRunners()
There is a lengthy comment in the declaration of AutoThreadTaskRunner and the
corresponding bug is http://crbug.com/145856. Basically the answer is that we
can't because the plugin main loop is stopped during shutdown and Thread::Stop()
has limitations that prevent us from stopping threads the way we would want them
to be stopped.

This CL is one step closer to the model that we will be able to stop the threads
earlier.

+
   // Task runner for the thread that is used for the UI. In the NPAPI
   // plugin this corresponds to the main plugin thread.
   virtual base::SingleThreadTaskRunner* ui_task_runner();
 
   // Task runner for the thread used by the ScreenRecorder to capture
   // the screen.
   virtual base::SingleThreadTaskRunner* capture_task_runner();
 
   // Task runner for the thread used to encode video streams.
   virtual base::SingleThreadTaskRunner* encode_task_runner();
@@ skipping 28 matching lines @@
 
   // A thread that hosts all encode operations.
   base::Thread encode_thread_;
 
   // A thread that hosts input injection.
   base::Thread desktop_thread_;
 
   // Thread for blocking IO operations.
   base::Thread file_thread_;
 
+  // Task runners wrapping the above threads. These should be declared after
+  // the corresponding threads to guarantee proper order of destruction.
+  scoped_refptr<base::SingleThreadTaskRunner> network_task_runner_;
+  scoped_refptr<base::SingleThreadTaskRunner> capture_task_runner_;
+  scoped_refptr<base::SingleThreadTaskRunner> encode_task_runner_;
+  scoped_refptr<base::SingleThreadTaskRunner> desktop_task_runner_;
+  scoped_refptr<base::SingleThreadTaskRunner> file_task_runner_;
+
   scoped_refptr<base::SingleThreadTaskRunner> ui_task_runner_;
 
   scoped_refptr<net::URLRequestContextGetter> url_request_context_getter_;
 
   DISALLOW_COPY_AND_ASSIGN(ChromotingHostContext);
 };
 
 }  // namespace remoting
 
 #endif  // REMOTING_HOST_CHROMOTING_HOST_CONTEXT_H_