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 "remoting/base/url_request_context_getter.h"
+
+namespace remoting {
+
+scoped_ptr<ChromotingClientRuntime> ChromotingClientRuntime::Create() {
+  return make_scoped_ptr(new ChromotingClientRuntime());
+}
+
+ChromotingClientRuntime::ChromotingClientRuntime() {
+  if (!base::MessageLoop::current()) {

[Sergey Ulanov, 2016/03/11 01:22:34]

Maybe just replace it with a DCHECK and make the calling code responsible for
MessageLoop creation. That way you can avoid the ifdefs below.

[nicholss, 2016/03/11 21:23:02]

Ok, I moved this out, it is starting to look more and more like
ChromotingHostContext. Maybe we could make a ChromotingContext in the future
with some options how to set the threads.

+    VLOG(1) << "Starting main message loop";
+    ui_loop_.reset(new base::MessageLoopForUI());
+#if defined(OS_IOS)
+    // On iOS we created a new message loop and now attach it.
+    base::MessageLoopForUI::current()->Attach();

[Lambros, 2016/03/10 00:52:15]

ui_loop_->Attach(); maybe?

[nicholss, 2016/03/11 21:23:02]

Done.

+#elif defined(OS_ANDROID)
+    // On Android, the UI thread is managed by Java, so we need to attach and
+    // start a special type of message loop to allow Chromium code to run tasks.
+    ui_loop_->Start();
+#else
+    NOTREACHED();

[Lambros, 2016/03/10 00:52:15]

This file seems to be specific to mobile clients.
I'm not sure it makes sense to compile this code on a platform where it will be
NOTREACHED() ?

It feels like this should be:
#error Not implemented.
instead.

[nicholss, 2016/03/11 21:23:02]

This is fixed with the moving of the main thread generation. #if's are moved
out.

+#endif
+  } else {
+    VLOG(1) << "Using existing main message loop";
+    ui_loop_.reset(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(&base::DoNothing));
+
+  display_task_runner_ = AutoThread::Create("native_disp", ui_task_runner_);
+  network_task_runner_ = AutoThread::CreateWithType(
+      "native_net", ui_task_runner_, base::MessageLoop::TYPE_IO);
+  file_task_runner_ = AutoThread::CreateWithType("native_file", ui_task_runner_,

[Lambros, 2016/03/10 00:52:15]

Adding a new thread (and passing it to URLRequestContextGetter) is a material
change on Android. It looks OK, but please make sure to test your changes on
that platform (at least a couple of connect/disconnect cycles).

[nicholss, 2016/03/11 21:23:02]

Testing now.

+                                                 base::MessageLoop::TYPE_IO);
+  url_requester_ =
+      new URLRequestContextGetter(network_task_runner_, file_task_runner_);
+}
+
+ChromotingClientRuntime::~ChromotingClientRuntime() {}
+
+}  // namespace remoting