Adding container class for chromoting client runtimes.

remoting/client/chromoting_client_runtime.cc

Index: remoting/client/chromoting_client_runtime.cc
diff --git a/remoting/client/chromoting_client_runtime.cc b/remoting/client/chromoting_client_runtime.cc
new file mode 100644
index 0000000000000000000000000000000000000000..cb580ce8a63de192c54f9a9736e9d2daeb519d37
--- /dev/null
+++ b/remoting/client/chromoting_client_runtime.cc
@@ -0,0 +1,60 @@
+// 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 "base/synchronization/waitable_event.h"

[Lambros, 2016/03/03 19:15:07]

not used?

+#include "net/url_request/url_request_context.h"

[Lambros, 2016/03/03 19:15:07]

not used?

+#include "net/url_request/url_request_context_builder.h"
+#include "remoting/base/util.h"
+
+namespace {
+
+void DoNothing() {
+}
+}  // namespace
+
+namespace remoting {
+
+ChromotingClientRuntime::ChromotingClientRuntime() {

[nicholss, 2016/03/03 00:55:16]

I am going to be using this in the iOS app and am thinking of this being the
parent of remote/client/jni/chromoting_jni_runtime

[Lambros, 2016/03/03 19:15:07]

We usually prefer aggregation instead of (non-interface) inheritance. Is there
some reason to prefer inheritance in this case?
https://google.github.io/styleguide/cppguide.html#Inheritance

The normal pattern is to have the cross-platform code call out to
platform-specific code via an interface. See for example:
remoting/host/setup/daemon_controller.h
and
remoting/host/setup/daemon_controller_delegate_{linux,mac.win}.h

+  if (!base::MessageLoop::current()) {
+    VLOG(1) << "Starting main message loop";
+    ui_loop_ = new base::MessageLoop(base::MessageLoop::TYPE_UI);

[Lambros, 2016/03/03 19:15:07]

Why are you starting a message-loop in this new code? Are you going to be
refactoring all the existing client code to use this new class?

+    base::MessageLoopForUI::current()->Attach();
+  } else {
+    VLOG(1) << "Using existing main message loop";
+    ui_loop_ = base::MessageLoopForUI::current();
+  }
+
+  VLOG(1) << "Spawning additional threads";

[Lambros, 2016/03/03 19:15:07]

Remove this log?

+
+  // |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_);

[Lambros, 2016/03/03 19:15:07]

Don't you need
#include "remoting/base/url_request_context_getter.h"
for this?

+
+}
+
+// static
+ChromotingClientRuntime* ChromotingClientRuntime::GetInstance() {
+  return base::Singleton<ChromotingClientRuntime>::get();
+}
+
+ChromotingClientRuntime::~ChromotingClientRuntime() {
+}
+
+}  // namespace remoting