[Chromoting] The Windows IT2Me host gets any new text items it finds on the clipboard.

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 5e9ff7651bbabbd3461f83595bca585df582983c..c9aba5efdeb70eb39315eaac708948dc47c74c5a 100644
--- a/remoting/host/chromoting_host_context.cc
+++ b/remoting/host/chromoting_host_context.cc
@@ -29,7 +29,9 @@ ChromotingHostContext::~ChromotingHostContext() {
 bool ChromotingHostContext::Start() {
   // Start all the threads.
   bool started = main_thread_.Start() && encode_thread_.Start() &&
-      jingle_thread_.Start() && desktop_thread_.Start() &&
+      jingle_thread_.Start() &&
+      desktop_thread_.StartWithOptions(
+          base::Thread::Options(MessageLoop::TYPE_UI, 0)) &&

[Sergey Ulanov, 2012/05/11 21:10:11]

On some platforms (mac and linux) it might be unsafe to start second UI thread.
AFAIK, on Mac only the main thread can be used for UI. On linux some glib/gtk
API's may not be thread-safe (e.g. gconf is not threadsafe).

I'm not sure we really need desktop_thread separate from ui_thread, so maybe we
could use the ui_thread everywhere we currently use desktop_thread?

[simonmorris, 2012/05/11 22:12:58]

Sounds good to me. But it'd be better to consult more widely on that question,
so I'll leave this CL until Monday.

[Wez, 2012/05/15 18:40:02]

As Sergey points out, we can only have multiple UI threads on Windows, so we
can't make desktop_thread_ a UI thread.

We run captures on a non-UI thread so that they don't impact activity on the UI
thread, which is most relevant in the NPAPI plugin, where the UI thread is the
plugin main thread.  In practice it's probably not an issue, but we'd need to do
some testing to confirm that.

In principle the desktop integration threading should be separate from
ChromotingHost threading, though - the integration components should be provided
with the UI thread in case they need it, and otherwise create any threads they
need themselves.

For this CL, can the clipboard handler trap change notifications on the UI
thread and hand them off to the desktop thread?

       io_thread_.StartWithOptions(
           base::Thread::Options(MessageLoop::TYPE_IO, 0)) &&
       file_thread_.StartWithOptions(