Support generic synchronization against an IPC::Channel

Support generic synchronization against an IPC::Channel

Exposes a generic way to synchronize against an IPC::Channel's
message FIFO.

A simple Event interface is introduced with a single Signal()
message, and an API is added to Channel/ChannelProxy to create
a new Event pipe, send one end over a Channel for the other
side to signal immediately, and pass the other end to anyone
who wants to synchronize against that Channel's FIFO.

See the new IPC test for a complete working example.

This feature is intended to help satisfy simple ordering
guarantees as we transition to Mojo IPC, while avoiding the
use of associated interfaces where strict per-message
FIFO is not really necessary.

BUG=361001, 612500

[Ken Rockot(use gerrit already), 2016-10-27 00:36:40]

Description was changed from

==========
Support generic synchronization against an IPC::Channel

Exposes a message for renderers to send one end of a generic
signalling pipe to the browser's IO thread over a Channel-associated
interface where it's signalled immediately.

This allows arbitrary clients to be synchronized against a boundary
in the source renderer's legacy IPC message queue to the browser.

This facility is exposed to renderers through a simple
RenderThreadImpl::CreateChannelSynchronizationEvent interface,
which returns a mojo::common::mojom::EventRequest. This request
may be bound by any client in any process to listen for a single
Signal() message.

For example usage in crappy pseudocode:

 renderer A:
    std::string new_id = GenerateID();

    // Register an ID in the browser
    GetChannel()->Send(new SampleHostMsg_RegisterID(new_id));

    // Send the ID over a direct pipe to renderer B.
    SendIDToRendererB(
        new_id,
        render_message_filter()->CreateChannelSynchronizationEvent());

 renderer B:
    void OnMessageFromRendererA(
        const std::string& id,
        mojo::common::mojom::EventRequest event_request) {
      // Make sure we don't race with the registration!
      WaitForEventToSignal(std::move(event_request));

      // We know the ID will have been registered in the browser
      // by the time the browser receives this message.
      GetChannel()->(new SampleHostMsg_QueryID(id));
    }

BUG=None
==========

to

==========
Support generic synchronization against an IPC::Channel

Exposes a message for renderers to send one end of a generic
signalling pipe to the browser's IO thread over a Channel-associated
interface where it's signalled immediately.

This allows arbitrary clients to be synchronized against a boundary
in the source renderer's legacy IPC message queue to the browser.

This facility is exposed to renderers through a simple
RenderThreadImpl::CreateChannelSynchronizationEvent interface,
which returns a mojo::common::mojom::EventRequest. This request
may be bound by any client in any process to listen for a single
Signal() message.

For example usage in crappy pseudocode:

 renderer A:
    std::string new_id = GenerateID();

    // Register an ID in the browser
    GetChannel()->Send(new SampleHostMsg_RegisterID(new_id));

    // Send the ID over a direct pipe to renderer B.
    SendIDToRendererB(
        new_id,
        render_message_filter()->CreateChannelSynchronizationEvent());

 renderer B:
    void OnMessageFromRendererA(
        const std::string& id,
        mojo::common::mojom::EventRequest event_request) {
      // Make sure we don't race with the registration!
      WaitForEventToSignal(std::move(event_request));

      // We know the ID will have been registered in the browser
      // by the time this code executes.
      GetChannel()->(new SampleHostMsg_QueryID(id));
    }

BUG=None
==========

[Ken Rockot(use gerrit already), 2016-10-27 00:38:35]

Patchset #1 (id:1) has been deleted

[Ken Rockot(use gerrit already), 2016-10-28 23:42:10]

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

[commit-bot: I haz the power, 2016-10-28 23:42:27]

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), 2016-10-28 23:46:14]

Description was changed from

==========
Support generic synchronization against an IPC::Channel

Exposes a message for renderers to send one end of a generic
signalling pipe to the browser's IO thread over a Channel-associated
interface where it's signalled immediately.

This allows arbitrary clients to be synchronized against a boundary
in the source renderer's legacy IPC message queue to the browser.

This facility is exposed to renderers through a simple
RenderThreadImpl::CreateChannelSynchronizationEvent interface,
which returns a mojo::common::mojom::EventRequest. This request
may be bound by any client in any process to listen for a single
Signal() message.

For example usage in crappy pseudocode:

 renderer A:
    std::string new_id = GenerateID();

    // Register an ID in the browser
    GetChannel()->Send(new SampleHostMsg_RegisterID(new_id));

    // Send the ID over a direct pipe to renderer B.
    SendIDToRendererB(
        new_id,
        render_message_filter()->CreateChannelSynchronizationEvent());

 renderer B:
    void OnMessageFromRendererA(
        const std::string& id,
        mojo::common::mojom::EventRequest event_request) {
      // Make sure we don't race with the registration!
      WaitForEventToSignal(std::move(event_request));

      // We know the ID will have been registered in the browser
      // by the time this code executes.
      GetChannel()->(new SampleHostMsg_QueryID(id));
    }

BUG=None
==========

to

==========
Support generic synchronization against an IPC::Channel

Exposes a generic way to synchronize against an IPC::Channel's
message FIFO.

A simple Event interface is introduced with a single Signal()
message, and an API is added to Channel/ChannelProxy to create
a new Event pipe, send one end over a Channel for the other
side to signal immediately, and pass the other end to anyone
who wants to synchronize against that Channel's FIFO.

See the new IPC test for a complete working example usage.

This feature is intended to help satisfy simple ordering
guarantees as we transition to Mojo IPC, while avoiding the
use of associated interfaces where strict per-message
FIFO is not really necessary.

BUG=361001,612500
==========

[Ken Rockot(use gerrit already), 2016-10-28 23:46:40]

Description was changed from

==========
Support generic synchronization against an IPC::Channel

Exposes a generic way to synchronize against an IPC::Channel's
message FIFO.

A simple Event interface is introduced with a single Signal()
message, and an API is added to Channel/ChannelProxy to create
a new Event pipe, send one end over a Channel for the other
side to signal immediately, and pass the other end to anyone
who wants to synchronize against that Channel's FIFO.

See the new IPC test for a complete working example usage.

This feature is intended to help satisfy simple ordering
guarantees as we transition to Mojo IPC, while avoiding the
use of associated interfaces where strict per-message
FIFO is not really necessary.

BUG=361001,612500
==========

to

==========
Support generic synchronization against an IPC::Channel

Exposes a generic way to synchronize against an IPC::Channel's
message FIFO.

A simple Event interface is introduced with a single Signal()
message, and an API is added to Channel/ChannelProxy to create
a new Event pipe, send one end over a Channel for the other
side to signal immediately, and pass the other end to anyone
who wants to synchronize against that Channel's FIFO.

See the new IPC test for a complete working example.

This feature is intended to help satisfy simple ordering
guarantees as we transition to Mojo IPC, while avoiding the
use of associated interfaces where strict per-message
FIFO is not really necessary.

BUG=361001,612500
==========

[Ken Rockot(use gerrit already), 2016-10-28 23:47:21]

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

[commit-bot: I haz the power, 2016-10-29 00:51:27]

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

[commit-bot: I haz the power, 2016-10-29 00:51:29]

Dry run: This issue passed the CQ dry run.

[yzshen1, 2016-11-04 17:08:26]

On 2016/10/28 23:47:22, Ken Rockot wrote:

Just trying to understand this CL better: Singling an event happens on the IO
thread, so if I send an IPC message targeting the UI thread, and then send an
event. When the event is signaled, there is no guarantee that the message
reaches its destination. I guess the use case you have in mind doesn't care
about this?

It seems an alternative is to send the event in the IPC message that we would
like to synchronize with, and let the receiver does the work of signaling. But
that assumes that we can modify the IPC message and its handler.

Thanks!