Preparations for Cast Host Extension

remoting/host/chromoting_host_context.cc

 // 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.
 
 #include "remoting/host/chromoting_host_context.h"
 
 #include <string>
 
 #include "base/bind.h"
 #include "remoting/base/auto_thread.h"
@@ skipping 16 matching lines @@
   audio_task_runner_ = AutoThread::CreateWithType(
       "ChromotingAudioThread", ui_task_runner_, base::MessageLoop::TYPE_IO);
 #endif  // !defined(OS_WIN)
 
   file_task_runner_ = AutoThread::CreateWithType(
       "ChromotingFileThread", ui_task_runner_, base::MessageLoop::TYPE_IO);
   input_task_runner_ = AutoThread::CreateWithType(
       "ChromotingInputThread", ui_task_runner_, base::MessageLoop::TYPE_IO);
   network_task_runner_ = AutoThread::CreateWithType(
       "ChromotingNetworkThread", ui_task_runner_, base::MessageLoop::TYPE_IO);
-  video_capture_task_runner_ =
-      AutoThread::Create("ChromotingCaptureThread", ui_task_runner_);
+  video_capture_task_runner_ = AutoThread::CreateWithType(
+      "ChromotingCaptureThread", ui_task_runner_, base::MessageLoop::TYPE_IO);

[aiguha, 2014/07/29 17:06:26]

(Based on comment from previous patch, but modified).

Discussed with wez@ offline but unresolved.
To summarize, the network and capture threads are provided to PeerConnection as
signalling and worker threads respectively. During its ICE establishment, 
PeerConnection at some point calls
remoting::ChromiumSocketFactory::CreateUdpSocket() on the worker thread
(capturer) and fails because of its non-IO MessageLoop. It looks like this
method is called several times on the correct (network) thread (i.e., it being
called on this thread might be a webrtc bug), but I could be mistaken.

Wez suggested we give PeerConnection two new chromium-compatible, IO threads
rather than attempt to map our network/capture to their signalling/worker. I
attempted to do this, but have three concerns:
1. ChromotingHostContext manages all threads for the chromoting host process, so
it seems incorrect to create threads outside of it, in a HostExtensionSession. I
could create two additional threads in ChromotingHostContext and pass them down,
but that sounds messy/overreaching for a HostExtension.
2. Once CastExtensionSession gets a hold of a ScreenCapturer, it needs to use
the existing capture thread (I believe) to capture frames. In the current setup,
this constraint is satisfied. If we're creating new threads, I'm not sure how
that would work.
3. Interaction between the ExtensionSession and ClientSession for
ExtensionMessages etc. needs to be on the network thread. Again, that is true of
the current setup, but not sure how it would work in the alternative one.

Any advice?

[Wez, 2014/08/01 01:14:14]

It may be possible to check in CreateUdpSocket() whether we're on an IO thread
and have it immediately fail. Better still, let's get a call-stack for that case
so we can determine whether it's a WebRTC bug. :)
It's OK to have the extension create its own threads, if it really needs to.
When you "steal" the ScreenCapturer via the shiny new OnCreateScreenCapturer
hook, you can use it on whichever thread you like so long as you also delete it
on that thread.
Should be identical. There's nothing magical about the ChromotingHostContext's
set of threads; it's really just a convenience class.

   video_encode_task_runner_ = AutoThread::Create(
       "ChromotingEncodeThread", ui_task_runner_);
 
   url_request_context_getter_ = new URLRequestContextGetter(
       network_task_runner_);
 }
 
 ChromotingHostContext::~ChromotingHostContext() {
 }
 
@@ skipping 49 matching lines @@
 ChromotingHostContext::video_encode_task_runner() {
   return video_encode_task_runner_;
 }
 
 scoped_refptr<net::URLRequestContextGetter>
 ChromotingHostContext::url_request_context_getter() {
   return url_request_context_getter_;
 }
 
 }  // namespace remoting