Legacy IPC vs. Mojo message ordering

[Balazs Engedy]

Hi,

We have the notion of associated groups to enforce FIFO ordering across multiple interfaces. Do we have a similar concept to enforce FIFO ordering between Mojo and legacy IPC?

In lieu of that, suppose I want to get some information to a RenderFrame (the data is the same for all frames), and I need this data to have arrived by the time the provisional document load is committed. What is the preferred out of these options:

1. Push the data to the renderer in advance, by sending a legacy IPC message from ContentBrowserClient::RenderProcessWillLaunch().
   
2. Push the data by sending a legacy IPC message from WebContentsObserver::RenderFrameCreated().
   
3. Pull the data through a sync Mojo call initiated from a RenderFrameObserver::DidCommitProvisionalLoad().
   
4. Pull the data through a sync legacy IPC message sent from a RenderFrameObserver::DidCommitProvisionalLoad().
   

Thanks,
Balazs

[Ken Rockot]

On Thu, Apr 21, 2016 at 1:55 PM, Balazs Engedy <eng...@chromium.org> wrote:

Hi,

We have the notion of associated groups to enforce FIFO ordering across multiple interfaces. Do we have a similar concept to enforce FIFO ordering between Mojo and legacy IPC?

Not yet. We have an implementation of the legacy IPC channel built on an associated group, and we're going to replace the old implementation with this one ASAP. We're still iterating on performance improvements before shipping that though. Once it lands you can peel an associated interface off the main channel to preserve FIFO between your pipe and legacy messages.

This is a few weeks out yet, so you probably want one of the options you mentioned instead. My knowledge of loading is insufficient to make a good recommendation there.

 

In lieu of that, suppose I want to get some information to a RenderFrame (the data is the same for all frames), and I need this data to have arrived by the time the provisional document load is committed. What is the preferred out of these options:

1. Push the data to the renderer in advance, by sending a legacy IPC message from ContentBrowserClient::RenderProcessWillLaunch().
   
2. Push the data by sending a legacy IPC message from WebContentsObserver::RenderFrameCreated().
   
3. Pull the data through a sync Mojo call initiated from a RenderFrameObserver::DidCommitProvisionalLoad().
   
4. Pull the data through a sync legacy IPC message sent from a RenderFrameObserver::DidCommitProvisionalLoad().
   

Thanks,
Balazs

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAD1Ejna6dqjVoHcpDxnXG8PufjYzBgqQQbBwciuqh0Z7yyVu2Q%40mail.gmail.com.

[Yuzhu Shen]

The mojo-based IPC channel only guarantees FIFO of received messages (legacy and Mojo) on the IO thread.

If legacy messages need to be forwarded to a different thread (say, the main thread), PostTask is used. That is not managed by Mojo; while Mojo has a different queue to manage its own messages that need to be forwarded. Therefore, FIFO is not guaranteed between those forwarded legacy messages and Mojo messages targeting the same thread.

Here is an illustration: https://docs.google.com/document/d/1nCQFvbk9gCFAC1hJXRUeAzb317mn0fyr9cHPn1lp14U/edit

If we deside that preserving the order is important, one possible solution is to let Mojo also manage forwarding of legacy messages.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgGzKsfvLgdu9WYN71dCunv0A13ReFVfsZ1Y%2BRCLb0nKjA%40mail.gmail.com.

[Nasko Oskov]

On Thu, Apr 21, 2016 at 3:05 PM, Yuzhu Shen <yzs...@chromium.org> wrote:

The mojo-based IPC channel only guarantees FIFO of received messages (legacy and Mojo) on the IO thread.

If legacy messages need to be forwarded to a different thread (say, the main thread), PostTask is used. That is not managed by Mojo; while Mojo has a different queue to manage its own messages that need to be forwarded. Therefore, FIFO is not guaranteed between those forwarded legacy messages and Mojo messages targeting the same thread.

Here is an illustration: https://docs.google.com/document/d/1nCQFvbk9gCFAC1hJXRUeAzb317mn0fyr9cHPn1lp14U/edit

If we deside that preserving the order is important, one possible solution is to let Mojo also manage forwarding of legacy messages.

If we don't provide FIFO for actual messages on the target thread, don't we face race conditions when moving components from existing legacy IPC to Mojo IPCs that rely on lifetime of objects which are managed by legacy IPC?

For example, the media/ code has been moving to Mojo, but in the same time they are tied to the lifetime of RenderFrame, which in turn is legacy IPC based.

 

On Thu, Apr 21, 2016 at 2:06 PM, Ken Rockot <roc...@chromium.org> wrote:

On Thu, Apr 21, 2016 at 1:55 PM, Balazs Engedy <eng...@chromium.org> wrote:

Hi,

We have the notion of associated groups to enforce FIFO ordering across multiple interfaces. Do we have a similar concept to enforce FIFO ordering between Mojo and legacy IPC?

Not yet. We have an implementation of the legacy IPC channel built on an associated group, and we're going to replace the old implementation with this one ASAP. We're still iterating on performance improvements before shipping that though. Once it lands you can peel an associated interface off the main channel to preserve FIFO between your pipe and legacy messages.

This is a few weeks out yet, so you probably want one of the options you mentioned instead. My knowledge of loading is insufficient to make a good recommendation there.

 

In lieu of that, suppose I want to get some information to a RenderFrame (the data is the same for all frames), and I need this data to have arrived by the time the provisional document load is committed. What is the preferred out of these options:

1. Push the data to the renderer in advance, by sending a legacy IPC message from ContentBrowserClient::RenderProcessWillLaunch().
   
2. Push the data by sending a legacy IPC message from WebContentsObserver::RenderFrameCreated().
   
3. Pull the data through a sync Mojo call initiated from a RenderFrameObserver::DidCommitProvisionalLoad().
   
4. Pull the data through a sync legacy IPC message sent from a RenderFrameObserver::DidCommitProvisionalLoad().
   

1, 2, and (3, 4) are very different lifetime semantics - process lifetime, frame lifetime, and document lifetime respectively. It will depend on the lifetime of the information you want to send and its scope (process, page, document).

 

Thanks,
Balazs

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAD1Ejna6dqjVoHcpDxnXG8PufjYzBgqQQbBwciuqh0Z7yyVu2Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgGzKsfvLgdu9WYN71dCunv0A13ReFVfsZ1Y%2BRCLb0nKjA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CABxY52BOaFM6kbjhBDjoRkDRfYf%2BZyguRvTKnH8SLDeUnn_ruQ%40mail.gmail.com.

[Ben Goodger (Google)]

On Thu, Apr 21, 2016 at 3:42 PM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Apr 21, 2016 at 3:05 PM, Yuzhu Shen <yzs...@chromium.org> wrote:

The mojo-based IPC channel only guarantees FIFO of received messages (legacy and Mojo) on the IO thread.

If legacy messages need to be forwarded to a different thread (say, the main thread), PostTask is used. That is not managed by Mojo; while Mojo has a different queue to manage its own messages that need to be forwarded. Therefore, FIFO is not guaranteed between those forwarded legacy messages and Mojo messages targeting the same thread.

Here is an illustration: https://docs.google.com/document/d/1nCQFvbk9gCFAC1hJXRUeAzb317mn0fyr9cHPn1lp14U/edit

If we deside that preserving the order is important, one possible solution is to let Mojo also manage forwarding of legacy messages.

If we don't provide FIFO for actual messages on the target thread, don't we face race conditions when moving components from existing legacy IPC to Mojo IPCs that rely on lifetime of objects which are managed by legacy IPC?

Ken is working on flipping on sending Chrome IPC messages via a primordial Mojo interface, which will allow ordering to be preserved with new Mojo interfaces associated with that primordial one.

-Ben

[Balazs Engedy]

That's great advice, thank you all!

Nasko, admittedly, the four alternatives were my overly transparent attempt at gauging enthusiasm for using sync Mojo calls. But from the looks of it, I'll stick to legacy IPC for now.

[Nick Carter]

Yuzhu's response suggested that this will only guarantee FIFO ordering of messages received on the IO thread.

Nasko's response suggested it will probably be important to have FIFO ordering for messages delivered to the UI thread. I agree.

Which one will we get?

 

[Ken Rockot]

Yuzhu's response refers to the current state of affairs with a Mojo-based IPC Channel enabled. There's additional work required to guarantee FIFO uniformly for all IPCs on all threads, and it's still not clear whether it's worth the development and runtime overhead to accomplish this.

 

Nasko's response suggested it will probably be important to have FIFO ordering for messages delivered to the UI thread. I agree.

What Nasko suggests is important but it certainly does not apply across all (or probably even most) IPCs today. It's possible we can address individual cases by coordinating specific message filters and interface bindings appropriately, in isolation.

 

Which one will we get?

The system remains flexible. The best answer I can give is that we'll get whatever makes the most practical sense once we've tackled some of the gnarlier conversion work.

 

[Yuzhu Shen]

IMO, maybe first we could do some investigation and get an idea how hard it is in general to convert features without FIFO ordering between legacy and mojo messages. There are probably features that don't need to preserve FIFO ordering with other features; or the ordering requirement is easy to get around.

If it turns out that plenty of the features are hard to convert without FIFO ordering, we can invest in adding support.

I imagine that eventually in fully mojo-ified Chrome, features should be decoupled to use separate FIFOs (i.e., message pipes). So this investigation is not a waste of time IMO.