Before this CL, the child process start-up flow went like this:
1.) Browser would create a Mojo invitation, with a mojom::ChildProcess
receiver, that ChildThreadImpl would recover and bind.
2.) ChildThreadImpl immediately creates a remote for its
ChildProcessHost so it can start queueing messages for the browser
process, even though it is not bound to the browser.
3.) ChildThreadImpl asynchronously waits for ChildProcess::Initialize
to be invoked by the browser process; this supplies a remote for
mojom::ChildProcessHostBootstrap, which the child process uses to
send the receiver for the remote created in (1).
4.) Browser receives this, binding it to either
RenderProcessHostImpl::io_thread_host_impl_ or ChildProcessHostImpl
In short, there's an awkward dance that has to be done between the
browser <-> renderer ((3) above), so that they can both immediately
initialize remotes for each other. This CL removes the extra IPC round
trip by removing ChildProcessHostBootstrap, and steps (3) & (4) above.
This is done by attaching a second message pipe to the mojo invitation
corresponding to the ChildProcessHost receiver, so the child process has
it immediately on init. At this point, the child process can create a
remote for the ChildProcessHost, and immediately bind it to the pipe
which is bound to the browser process's ChildProcessHost receiver.
Bug: N/A
R=haraken@chromium.org,rockot@google.com
Change-Id: I8f7b4b698b82e25d1c5c991c9639e57de05a6360
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2393158
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Martin Barbella <mbarbella@chromium.org>
Reviewed-by: Tal Pressman <talp@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805037}
1f77378d5e