Preparations for Cast Host Extension

remoting/host/chromoting_host_context.cc

Index: remoting/host/chromoting_host_context.cc
diff --git a/remoting/host/chromoting_host_context.cc b/remoting/host/chromoting_host_context.cc
index 0145f9990c53001c34cd4d024b5bd1ba521ecc50..abac0f04015e92a93ce36826bccd9ffa2e546114 100644
--- a/remoting/host/chromoting_host_context.cc
+++ b/remoting/host/chromoting_host_context.cc
@@ -34,8 +34,8 @@ ChromotingHostContext::ChromotingHostContext(
       "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_);