Implements Mojo-based waiting for IPC::SyncChannel

Implements Mojo-based waiting for IPC::SyncChannel

Changes SyncChannel et al to use Mojo message pipe handles
and mojo::SyncHandleRegistry for sync waiting in lieu of
base::WaitableEvent.

This is necessary to support sync Mojo interface messages
without risk of deadlock.

BUG=612500
Committed: https://crrev.com/64e65de0553abe1c870978ec4dee77da14d93d9e
Cr-Commit-Position: refs/heads/master@{#401090}

[Ken Rockot(use gerrit already), 2016-06-21 16:52:33]

rockot@chromium.org changed reviewers:
+ jam@chromium.org

[Ken Rockot(use gerrit already), 2016-06-21 17:29:38]

Patchset #4 (id:60001) has been deleted

[Ken Rockot(use gerrit already), 2016-06-21 17:29:43]

Patchset #3 (id:40001) has been deleted

[Ken Rockot(use gerrit already), 2016-06-21 17:29:46]

Patchset #2 (id:20001) has been deleted

[Ken Rockot(use gerrit already), 2016-06-21 17:29:49]

Patchset #1 (id:1) has been deleted

[Ken Rockot(use gerrit already), 2016-06-21 17:34:57]

Please take a look. This is a reland of the bits that were reverted last week,
with some additional changes:

 - SyncMessageFilter also treats IO MessageLoop destruction as a shutdown event.
   This is necessary since it now uses an async WaitableEventWatcher on the IO
   thread to forward to a MojoEvent.

 - SyncChannel::Send guards against races between SyncContext::Push and
   SyncContext::CancelPendingSends which could cause a sync wait to begin
   after channel closure or shutdown has signaled, causing the wait to block
   indefinitely.

Unfortunately I've been unable to repro any of the hangs seen last time this
landed,
so it's hard to tell whether this fixes them. But logically the additional
changes
seem necessary to avoid potential hangs.

[jam, 2016-06-21 20:09:05]

lgtm

https://codereview.chromium.org/2072393003/diff/80001/ipc/ipc_sync_channel.cc
File ipc/ipc_sync_channel.cc (right):

https://codereview.chromium.org/2072393003/diff/80001/ipc/ipc_sync_channel.cc...
ipc/ipc_sync_channel.cc:57: // be cleaned up when no longer in use.
is cleaning up really necessary? i.e. is this premature optimization? why not
just create it lazily but then leave it alive?

[Ken Rockot(use gerrit already), 2016-06-21 20:12:23]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-06-21 20:12:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2072393003/80001

[Ken Rockot(use gerrit already), 2016-06-21 20:15:42]

On 2016/06/21 at 20:09:05, jam wrote:
> lgtm
> 
> https://codereview.chromium.org/2072393003/diff/80001/ipc/ipc_sync_channel.cc
> File ipc/ipc_sync_channel.cc (right):
> 
>
https://codereview.chromium.org/2072393003/diff/80001/ipc/ipc_sync_channel.cc...
> ipc/ipc_sync_channel.cc:57: // be cleaned up when no longer in use.
> is cleaning up really necessary? i.e. is this premature optimization? why not
just create it lazily but then leave it alive?

I wouldn't call it a premature optimization. To be fair I only did this because
LSan for some reason complained when I used a simple Leaky LazyInstance and I
didn't take the time to figure out why.

[commit-bot: I haz the power, 2016-06-21 20:18:08]

Committed patchset #1 (id:80001)

[commit-bot: I haz the power, 2016-06-21 20:21:14]

Description was changed from

==========
Implements Mojo-based waiting for IPC::SyncChannel

Changes SyncChannel et al to use Mojo message pipe handles
and mojo::SyncHandleRegistry for sync waiting in lieu of
base::WaitableEvent.

This is necessary to support sync Mojo interface messages
without risk of deadlock.

BUG=612500
==========

to

==========
Implements Mojo-based waiting for IPC::SyncChannel

Changes SyncChannel et al to use Mojo message pipe handles
and mojo::SyncHandleRegistry for sync waiting in lieu of
base::WaitableEvent.

This is necessary to support sync Mojo interface messages
without risk of deadlock.

BUG=612500

Committed: https://crrev.com/64e65de0553abe1c870978ec4dee77da14d93d9e
Cr-Commit-Position: refs/heads/master@{#401090}
==========

[commit-bot: I haz the power, 2016-06-21 20:21:15]

Patchset 1 (id:??) landed as
https://crrev.com/64e65de0553abe1c870978ec4dee77da14d93d9e
Cr-Commit-Position: refs/heads/master@{#401090}