IPC::ChannelMojo: Introduce IPC::MojoBootstrap for Windows

content/browser/renderer_host/render_process_host_impl.cc

Index: content/browser/renderer_host/render_process_host_impl.cc
diff --git a/content/browser/renderer_host/render_process_host_impl.cc b/content/browser/renderer_host/render_process_host_impl.cc
index f6f0853349506330c61438a07b0d9a403f69682e..03fcef422c31404dbd51f9cd66250cf02a9adc3a 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -2087,6 +2087,8 @@ void RenderProcessHostImpl::OnProcessLaunched() {
   // Chrome IPC message.
   MaybeActivateMojo();
 
+  channel_->OnClientLaunched(child_process_launcher_->GetHandle());

[viettrungluu, 2014/09/15 20:19:43]

It feels a bit suboptimal to require an extra explicit call....

I wonder since the listener already get a process ID back (in
OnChannelConnected), we couldn't just use that (and OpenProcess) to get a handle
to the child there....

[Hajime Morrita, 2014/09/15 22:01:36]

Yeah...
I tried that but it didn't work.
A handle returned from OpenProcess() is different from one that 
is returned from CreateProcess(), and DuplicateHandle() call with that 
handle declines the request saying "access denied" :-/

[viettrungluu, 2014/09/15 22:37:27]

I was afraid of something like that.

This design still seems a bit odd and fragile to me. (E.g., are there other
places where we launch processes, where we don't call OnClientLaunched()?
Obviously, this doesn't affect us now, but it could be a source of problems in
the future.)

Unfortunately, I don't really have any idea that's much better (short of much
bigger refactoring). Maybe darin or jam might have some good ideas?

+
   while (!queued_messages_.empty()) {
     Send(queued_messages_.front());
     queued_messages_.pop();