Chrome IPC -> Mojo

[Ken Rockot]

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet. In particular I think it would be a bit unfortunate if we started out by forcing associated interfaces everywhere. At least maybe we could do something a little less drastic, like have associated interfaces for large tangled (but distinct) bundles of IPC like RenderFrame et al.

Cheers!

Ken

[John Abd-El-Malek]

Here's the doc mentioned in yesterday's meeting: https://docs.google.com/a/google.com/spreadsheets/d/1McxT38rVZFj7mjmXPr-NDLXREBPcHqZcBBW47iKc920/edit?usp=sharing. There's a first pass of all the current chrome IPC files. The majority of these are pretty specific to a feature and therefore wouldn't use/benefit from a shared service, so I think we should start with those.

--
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%2BapAgHsax1t4gnbzNJuSLXTZG0rcmOLq7pZrms5nTNyQ0Q4BA%40mail.gmail.com.

[Nasko Oskov]

On Thu, Jan 14, 2016 at 8:09 AM, Ken Rockot <roc...@chromium.org> wrote:

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet.

It is my understanding that we won't guarantee that messages sent through Chrome IPC and Mojo IPC from one process will arrive in the exact same order in the other process. If that is the case, wouldn't leaving this behavior intact lead to subtle races and hard to diagnose bugs, even security issues?

 

In particular I think it would be a bit unfortunate if we started out by forcing associated interfaces everywhere. At least maybe we could do something a little less drastic, like have associated interfaces for large tangled (but distinct) bundles of IPC like RenderFrame et al.

Cheers!

Ken

--

[Ken Rockot]

On Thu, Jan 14, 2016 at 8:58 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:09 AM, Ken Rockot <roc...@chromium.org> wrote:

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet.

It is my understanding that we won't guarantee that messages sent through Chrome IPC and Mojo IPC from one process will arrive in the exact same order in the other process. If that is the case, wouldn't leaving this behavior intact lead to subtle races and hard to diagnose bugs, even security issues?

Yes that's the main concern there. We will realistically have to enforce some ordering between Chrome IPC and Mojo IPC in various places. We can accomplish this by using associated interfaces (a way of guaranteeing ordering across a set of arbitrary Mojo interface pipes), with one such interface being used as the transport for legacy IPC messages.

The question here is whether we apply that approach broadly to the entire browser, forcing all IPC for a process to go over the same pipe, or whether we address it a little more granularly, with independent bundles of associated interfaces for different subsystems on a case-by-case basis. Of course the latter approach still carries with it some possibility of subtle misery, but it might be a nice compromise, leaving us with less mess to disentangle during the next phase of the project.

[Nasko Oskov]

On Thu, Jan 14, 2016 at 9:07 AM, Ken Rockot <roc...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:58 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:09 AM, Ken Rockot <roc...@chromium.org> wrote:

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet.

It is my understanding that we won't guarantee that messages sent through Chrome IPC and Mojo IPC from one process will arrive in the exact same order in the other process. If that is the case, wouldn't leaving this behavior intact lead to subtle races and hard to diagnose bugs, even security issues?

Yes that's the main concern there. We will realistically have to enforce some ordering between Chrome IPC and Mojo IPC in various places. We can accomplish this by using associated interfaces (a way of guaranteeing ordering across a set of arbitrary Mojo interface pipes), with one such interface being used as the transport for legacy IPC messages.

Thanks for the details!

 

The question here is whether we apply that approach broadly to the entire browser, forcing all IPC for a process to go over the same pipe, or whether we address it a little more granularly, with independent bundles of associated interfaces for different subsystems on a case-by-case basis. Of course the latter approach still carries with it some possibility of subtle misery, but it might be a nice compromise, leaving us with less mess to disentangle during the next phase of the project.

My main point of view looking at this is that any subsystem that relies on RenderFrame/RenderFrameHost, must be guaranteed ordering with the RenderFrame/RenderFrameHost interface.

[Dmitry Skiba]

Is there any idea how long it will take to complete the transition? 3 month? by the end of 2016? 

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

[Nick Carter]

On Thu, Jan 14, 2016 at 9:51 AM, 'Dmitry Skiba' via chromium-mojo <chromi...@chromium.org> wrote:

Is there any idea how long it will take to complete the transition? 3 month? by the end of 2016? 

On Thu, Jan 14, 2016 at 9:34 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 9:07 AM, Ken Rockot <roc...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:58 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:09 AM, Ken Rockot <roc...@chromium.org> wrote:

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet.

It is my understanding that we won't guarantee that messages sent through Chrome IPC and Mojo IPC from one process will arrive in the exact same order in the other process. If that is the case, wouldn't leaving this behavior intact lead to subtle races and hard to diagnose bugs, even security issues?

Yes that's the main concern there. We will realistically have to enforce some ordering between Chrome IPC and Mojo IPC in various places. We can accomplish this by using associated interfaces (a way of guaranteeing ordering across a set of arbitrary Mojo interface pipes), with one such interface being used as the transport for legacy IPC messages.

Thanks for the details!

 

The question here is whether we apply that approach broadly to the entire browser, forcing all IPC for a process to go over the same pipe, or whether we address it a little more granularly, with independent bundles of associated interfaces for different subsystems on a case-by-case basis. Of course the latter approach still carries with it some possibility of subtle misery, but it might be a nice compromise, leaving us with less mess to disentangle during the next phase of the project.

My main point of view looking at this is that any subsystem that relies on RenderFrame/RenderFrameHost, must be guaranteed ordering with the RenderFrame/RenderFrameHost interface.

If I'm reviewing a change where we're taking a class that's implemented via mature, legacy IPC and converting it to mojo, giving an 'lgtm' will just be much, much easier if we don't have to puzzle through the implications of message reordering.

Is the nondeterminism considered a mojo feature? I'm not sure I understand why this is desirable in the first place.

In particular I think it would be a bit unfortunate if we started out by forcing associated interfaces everywhere. At least maybe we could do something a little less drastic, like have associated interfaces for large tangled (but distinct) bundles of IPC like RenderFrame et al.

Cheers!

Ken

--
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%2BapAgHsax1t4gnbzNJuSLXTZG0rcmOLq7pZrms5nTNyQ0Q4BA%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/CAA%3DmyAtONf9DRyjXs59arz03A8zYpj1WakESeyH1ApWo6nS%2Bog%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/CABWS%2BBySt9ougG%2BPb7ms6m6siY07h%2BJ0hPJX2xh-8GzKg%2BH0Tg%40mail.gmail.com.

[John Abd-El-Malek]

It would be helpful to look at concrete examples, as we start conversion, to see how ordering difference can affect this. My gut feeling is that for many, this shouldn't matter. So we should avoid adding extra complexity until we understand precisely where it's needed, and then only keep order for specific interfaces that we know need it instead of more broadly.

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

[Ken Rockot]

On Thu, Jan 14, 2016 at 9:51 AM, Dmitry Skiba <dsk...@google.com> wrote:

Is there any idea how long it will take to complete the transition? 3 month? by the end of 2016? 

End of 2016 is tentative target.

[Ken Rockot]

On Thu, Jan 14, 2016 at 10:00 AM, Nick Carter <ni...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 9:51 AM, 'Dmitry Skiba' via chromium-mojo <chromi...@chromium.org> wrote:

Is there any idea how long it will take to complete the transition? 3 month? by the end of 2016? 

On Thu, Jan 14, 2016 at 9:34 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 9:07 AM, Ken Rockot <roc...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:58 AM, Nasko Oskov <na...@chromium.org> wrote:

On Thu, Jan 14, 2016 at 8:09 AM, Ken Rockot <roc...@chromium.org> wrote:

Gomojo! Filed a tracking bug here: https://code.google.com/p/chromium/issues/detail?id=577685

As it turns out I'm blocking everything ;)  What would help the most in moving this forward ASAP would be moar documentation (http://crbug.com/577693).

Please add more blockers if you see specific work you believe is a necessary precursor. We should also file and link bugs for porting various subsystems as we begin to prioritize and work through them.

Finally regarding the question of ordering between Chrome and Mojo IPC: I didn't file a bug to do this work because I'm not convinced we should take any broad action just yet.

It is my understanding that we won't guarantee that messages sent through Chrome IPC and Mojo IPC from one process will arrive in the exact same order in the other process. If that is the case, wouldn't leaving this behavior intact lead to subtle races and hard to diagnose bugs, even security issues?

Yes that's the main concern there. We will realistically have to enforce some ordering between Chrome IPC and Mojo IPC in various places. We can accomplish this by using associated interfaces (a way of guaranteeing ordering across a set of arbitrary Mojo interface pipes), with one such interface being used as the transport for legacy IPC messages.

Thanks for the details!

 

The question here is whether we apply that approach broadly to the entire browser, forcing all IPC for a process to go over the same pipe, or whether we address it a little more granularly, with independent bundles of associated interfaces for different subsystems on a case-by-case basis. Of course the latter approach still carries with it some possibility of subtle misery, but it might be a nice compromise, leaving us with less mess to disentangle during the next phase of the project.

My main point of view looking at this is that any subsystem that relies on RenderFrame/RenderFrameHost, must be guaranteed ordering with the RenderFrame/RenderFrameHost interface.

If I'm reviewing a change where we're taking a class that's implemented via mature, legacy IPC and converting it to mojo, giving an 'lgtm' will just be much, much easier if we don't have to puzzle through the implications of message reordering.

Is the nondeterminism considered a mojo feature? I'm not sure I understand why this is desirable in the first place.

That's a loaded question. No, nondeterminism is not considered a Mojo feature. Mojo does not introduce non-determinism in isolation. Where it makes sense to enforce ordering consistency between Mojo IPC and legacy IPC, we'll obviously have to do it.

It does not make sense, in my opinion, to enforce strict ordering across every subsystem of the browser. There are many instances where there is a clear separation of concerns and no subtle reliance on the ordering of other messages. We would like to get more of the browser into such a state, and this is one of the first steps in that direction.

The much broader long-term goal here is to migrate Chrome toward a system services architecture. There is going to be complexity along the way, but the complexity itself is of course not the goal.

[Leon]

Hi, I'm interested in the new Mojo IPC and I think I've understood the mechanism and be familiar with creating/consuming Mojo services, 

and, I'm very happy to contribute for the 'Chrome IPC --> Mojo services' conversion work here, is it possible? :)

Actually I've done some conversion work  for Chromium before, such as ImageDownloader and VibrationManager Mojo services. Eager to your feedback, Thanks~

[Anand K. Mistry]

Hey, welcome back. My preference is to wait a few more weeks. There are a lot of different things going on in this space, many of which are core to how Mojo is going to be used going forward. So maybe now's not the right time to start working on wholesale conversion.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/4e59791f-23ac-497a-b73a-bcdc1e774c05%40chromium.org.

[Leon]

Hi, Anand, Thanks a lot for kindly explanation. Yeah I see the wholesale conversion work is just starting and some infra TODOs are ongoing such as message order issue in case of both Mojo IPC and Chrome IPC working together for one component, component migration via Mojo IPC between chrome/content/blink modules, and sync call support issue etc.  

Plus the already landed new Mojo EDK with Ports, I just think all of these are so exciting job.. Anyway, I'd like to catch up with what is happening here :) And at the meanwhile, I'll continue studying around to get more clear understanding and try to dig into some specific item. Hope to work together via codereview soon ;-)