Remove 2-stage RenderWidget initialization

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 2c00dff52930b46a7a7747b3508974658d066e34..aad0cd4e760693aa44baa5bf68f5d40822828d81 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -1483,6 +1483,11 @@ base::ProcessHandle RenderProcessHostImpl::GetHandle() const {
   return child_process_launcher_->GetProcess().Handle();
 }
 
+bool RenderProcessHostImpl::IsReady() const {

[ncarter (slow), 2015/09/29 18:28:40]

It might be worthwhile to add a comment here to point out that the
channel-connection (which initializes GetPeerPID) and the
result-of-process-launch (GetHandle()) can happen in either ordering.

[piman, 2015/09/29 23:54:27]

Done.

+  return GetHandle() && channel_ &&
+         (channel_->GetPeerPID() != base::kNullProcessId);
+}
+
 bool RenderProcessHostImpl::Shutdown(int exit_code, bool wait) {
   if (run_renderer_in_process())
     return false;  // Single process mode never shuts down the renderer.
@@ -1602,6 +1607,13 @@ bool RenderProcessHostImpl::OnMessageReceived(const IPC::Message& msg) {
 }
 
 void RenderProcessHostImpl::OnChannelConnected(int32 peer_pid) {
+  if (IsReady()) {
+    // Send RenderProcessReady only if we already received the process handle.
+    FOR_EACH_OBSERVER(RenderProcessHostObserver,
+                      observers_,
+                      RenderProcessReady(this));
+  }
+
 #if defined(IPC_MESSAGE_LOG_ENABLED)
   Send(new ChildProcessMsg_SetIPCLoggingEnabled(
       IPC::Logging::GetInstance()->Enabled()));
@@ -2404,6 +2416,13 @@ void RenderProcessHostImpl::OnProcessLaunched() {
     queued_messages_.pop();
   }
 
+  if (IsReady()) {
+    // Send RenderProcessReady only if the channel is already connected.
+    FOR_EACH_OBSERVER(RenderProcessHostObserver,
+                      observers_,
+                      RenderProcessReady(this));

[ncarter (slow), 2015/09/29 18:28:40]

The intent here, right, is to call RenderProcessReady from exactly one of
OnProcessLaunched or OnChannelConnected, whichever occurs last?

We were actually just working through the ChildProcessHost variant of this
pattern, http://crbug.com/484937. In my experiments on that bug, it seemed like
OnChannelConnected usually happened first -- do you know if we have adequate
test coverage of the other ordering?

[piman, 2015/09/29 23:54:27]

Right, the contract is, RenderProcessReady is only sent once both of:
- GetHandle() returns a valid handle
- the channel is connected (channel_->GetPeerPid() is valid)
are true.
(this corresponds to IsReady() is true).

GetHandle() is valid once OnProcessLaunched() is called (as a posted task from
the process launcher thread)
The channel is known to be connected once OnChannelConnected() is called (as a
posted task from the IO thread, after the newly running process sends the hello
message).

The 2 posted tasks race with each other, but since they are separate tasks, only
one of the callback will observe the IsReady() transition from false to true.
Actually, here, I found that it was usually the opposite, GetHandle() being
valid but the channel was not yet connected (I had a patch originally that only
waited for the process to be launched, but one of the tests broke on Windows,
namely
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...
, see ExtensionManagementApiEscalationTest /
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ext...
as to why).

In a way it makes sense, because the LAUNCHER->UI hop is generally shorter than
the LAUNCHER->new process main->IO->UI multiple hop.

[ncarter (slow), 2015/09/30 20:30:33]

I think I had it somewhat backwards, but the behavior probably varies quite a
bit depending on the OS and number of cores. In my own testing, on Windows/z620,
I actually was having to sandbag the child process launcher to force the
channel-connection to win -- so that matches what you've seen. But in the
originally-reported bug (which was reported against nacl launching, on cros),
the channel-connection was winning on average. It may be that there are extra
process hops involved in nacl processes that delay the result of process
creation? Something something zygote process?

+  }

[ncarter (slow), 2015/09/29 18:28:40]

I like how this operates, but I'm wondering if we should be worried about it
evolving so that RenderProcessReady comes to be called twice?

We could protect against that by adding an explicit, redundant boolean member
(process_ready_) to protect against double notification, or else to make sure
that there's a DCHECK in one of the observers_ (maybe a test-only,
ContentBrowserSanityChecker style DCHECK?).

[piman, 2015/09/29 23:54:27]

I added a DCHECK. I'm fairly confident that we call only once (see above why).

[ncarter (slow), 2015/09/30 20:30:33]

Great. I'm confident that it's correct now, but I worry that it could be a
little fragile as the code evolves.

+

[ncarter (slow), 2015/09/29 18:28:40]

FYI: an alternative approach discussed in bug 484937, is to just initialize
Handle() from |peer_pid| at OnChannelConnected time, and do the notification
exclusively from OnChannelConnected. This has the advantage of removing the
latency impact of waiting for the process-launch result, but it puts a little
more trust in |peer_pid| (though I'd hope that's okay since there's the
authentication secret).

[piman, 2015/09/29 23:54:27]

I believe GetHandle and channel_->GetPeerPid return different things (they're a
different type on Windows). As much as it looks like we can extract the process
id from the process handle, I don't know that the opposite is true (not a
Windows expert here....)
I also think there may be places where we need the process handle before the
channel is connected. E.g. the task manager uses the process handle to do
things.

[ncarter (slow), 2015/09/30 20:30:33]

You definitely can go pid->handle on Windows, but it's a syscall to do so, and
it'll fail if the process has died in the meantime. Usually those failure cases
are a headache to deal with and it's a better practice to keep things as handles
all the way through. However, this here is the earliest possible moment.

In the ChildProcessHost case, we actually already open the handle from the pid,
just before calling OnChannelConnected:
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/chi....
It was because we already had a handle right there, in the calling stack frame,
that I started wondering if we should just use that.

Definitely waiting for both results (as your patch does) feels like the
cleanest, safest approach. There are latency savings to be had only if it's
common for the channel to connect before we hear back from the launcher.

 #if defined(ENABLE_WEBRTC)
   // TODO(erikchen): Remove ScopedTracker below once http://crbug.com/465841
   // is fixed.