Adding container class for chromoting client runtimes.

remoting/client/chromoting_client_runtime.cc

+// Copyright 2016 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 "remoting/client/chromoting_client_runtime.h"
+
+#include "base/bind.h"
+#include "base/logging.h"
+#include "base/memory/singleton.h"
+#include "remoting/base/url_request_context_getter.h"
+
+namespace {
+
+void DoNothing() {

[Sergey Ulanov, 2016/03/04 22:50:17]

Please use base::DoNothing().

[nicholss, 2016/03/07 18:32:36]

Done.

+}
+}  // namespace
+
+namespace remoting {
+
+ChromotingClientRuntime::ChromotingClientRuntime() {
+  if (!base::MessageLoop::current()) {
+    VLOG(1) << "Starting main message loop";
+    ui_loop_ = new base::MessageLoop(base::MessageLoop::TYPE_UI);
+    base::MessageLoopForUI::current()->Attach();
+  } else {
+    VLOG(1) << "Using existing main message loop";
+    ui_loop_ = base::MessageLoopForUI::current();
+  }
+
+  // |ui_loop_| runs on the main thread, so |ui_task_runner_| will run on the
+  // main thread.  We can not kill the main thread when the message loop becomes
+  // idle so the callback function does nothing (as opposed to the typical
+  // base::MessageLoop::QuitClosure())
+  ui_task_runner_ = new AutoThreadTaskRunner(ui_loop_->task_runner(),
+                                             base::Bind(&::DoNothing));
+
+  network_task_runner_ = AutoThread::CreateWithType(
+      "native_net", ui_task_runner_, base::MessageLoop::TYPE_IO);
+  file_task_runner_ = AutoThread::CreateWithType(
+      "native_file", ui_task_runner_, base::MessageLoop::TYPE_IO);
+
+  url_requester_ =
+      new URLRequestContextGetter(network_task_runner_, file_task_runner_);
+
+}
+
+// static
+ChromotingClientRuntime* ChromotingClientRuntime::GetInstance() {
+  return base::Singleton<ChromotingClientRuntime>::get();

[Sergey Ulanov, 2016/03/04 22:50:17]

Does this need to be a singleton?
Potentially there may be multiple concurrent sessions and ideally we'd want to
use separate objects for each of them (e.g. to avoid sharing threads).

[nicholss, 2016/03/07 18:32:36]

It is very convenient if this is a singleton. 

It gives a way to get access to the runtime threads without having to pass a
pointer to the container object everywhere. If someone wanted to manage multiple
sessions, potentially the client viewer could be new process or we make a new
kind of runtime, but for the case of mobile it is easier to have the runtime as
a singleton. 

[Sergey Ulanov, 2016/03/08 18:53:46]

There are cases when we will need to have multiple concurrent sessions, so it's
better to support this case from the start. We already pass all threads both in
the client and in the host without singletons (except on Android, but Lambros is
working on cleaning it up: crbug.com/526336). I don't think that it introduced
any extra complexity. Passing task_runner makes dependency between dependencies
on threads very explicit.

[nicholss, 2016/03/08 21:20:25]

Done.

+}
+
+ChromotingClientRuntime::~ChromotingClientRuntime() {
+}
+
+}  // namespace remoting