Avoid a thread hop when initializing IPC to new processes

Avoid a thread hop when initializing IPC to new processes

ChildProcessLauncher waits until receiving a successful launch
notification on its host thread before completing the low-level
IPC pipe connection to a new child process.

This means that even after a process is successfully launched
on the launcher thread, we must wait until a task can run on
the host thread (UI or IO, typically) before the new child
process's main thread can be unblocked (it's waiting on a sync
broker message to initialize IPC).

This CL instead begins browser-side initialization of IPC as
soon as the new process handle is known (synchronously after
LaunchProcess on most platforms, async on the launcher thread
for Android).

We still incur the cost of an internal PostTask to the IO thread
within the EDK before browser-side initialization can complete,
but that can be removed in a future CL.

This takes advantage of the new PendingProcessConnection EDK API
to ensure safe handling of any potential failure cases.

BUG=682794

[Ken Rockot(use gerrit already), 2017-02-09 03:38:16]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-09 03:38:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2017-02-09 03:39:55]

Description was changed from

==========
Avoid a thread hop when initializing child IPC to new processes

ChildProcessLauncher waits until receiving a successful launch
notification on its host thread before completing the low-level
IPC pipe connection to a new child process.

This means that even after a process is successfully launched
on the launcher thread, we must wait until a task can run on
the host thread (UI or IO, typically) before the new child
process's main thread can be unblocked (it's waiting on a sync
broker message to initialize IPC).

This CL instead begins browser-side initialization of IPC as
soon as the new process handle is known (synchronously after
LaunchProcess on most platforms, async on the launcher thread
for Android).

We still incur the cost of an internal PostTask to the IO thread
within the EDK before browser-side initialization can complete,
but that can be removed in a future CL.

BUG=682794
==========

to

==========
Avoid a thread hop when initializing child IPC to new processes

ChildProcessLauncher waits until receiving a successful launch
notification on its host thread before completing the low-level
IPC pipe connection to a new child process.

This means that even after a process is successfully launched
on the launcher thread, we must wait until a task can run on
the host thread (UI or IO, typically) before the new child
process's main thread can be unblocked (it's waiting on a sync
broker message to initialize IPC).

This CL instead begins browser-side initialization of IPC as
soon as the new process handle is known (synchronously after
LaunchProcess on most platforms, async on the launcher thread
for Android).

We still incur the cost of an internal PostTask to the IO thread
within the EDK before browser-side initialization can complete,
but that can be removed in a future CL.

This takes advantage of the new PendingProcessConnection EDK API
to ensure safe handling of any potential failure cases.

BUG=682794
==========

[commit-bot: I haz the power, 2017-02-09 04:04:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-09 04:04:36]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Ken Rockot(use gerrit already), 2017-02-09 08:57:16]

Description was changed from

==========
Avoid a thread hop when initializing child IPC to new processes

ChildProcessLauncher waits until receiving a successful launch
notification on its host thread before completing the low-level
IPC pipe connection to a new child process.

This means that even after a process is successfully launched
on the launcher thread, we must wait until a task can run on
the host thread (UI or IO, typically) before the new child
process's main thread can be unblocked (it's waiting on a sync
broker message to initialize IPC).

This CL instead begins browser-side initialization of IPC as
soon as the new process handle is known (synchronously after
LaunchProcess on most platforms, async on the launcher thread
for Android).

We still incur the cost of an internal PostTask to the IO thread
within the EDK before browser-side initialization can complete,
but that can be removed in a future CL.

This takes advantage of the new PendingProcessConnection EDK API
to ensure safe handling of any potential failure cases.

BUG=682794
==========

to

==========
Avoid a thread hop when initializing IPC to new processes

ChildProcessLauncher waits until receiving a successful launch
notification on its host thread before completing the low-level
IPC pipe connection to a new child process.

This means that even after a process is successfully launched
on the launcher thread, we must wait until a task can run on
the host thread (UI or IO, typically) before the new child
process's main thread can be unblocked (it's waiting on a sync
broker message to initialize IPC).

This CL instead begins browser-side initialization of IPC as
soon as the new process handle is known (synchronously after
LaunchProcess on most platforms, async on the launcher thread
for Android).

We still incur the cost of an internal PostTask to the IO thread
within the EDK before browser-side initialization can complete,
but that can be removed in a future CL.

This takes advantage of the new PendingProcessConnection EDK API
to ensure safe handling of any potential failure cases.

BUG=682794
==========

[Ken Rockot(use gerrit already), 2017-02-10 00:11:35]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-10 00:12:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-10 00:37:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-10 00:37:09]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)