Google Groups


Darin Fisher Oct 7, 2013 12:48 AM
Posted in group: Chromium-dev

Hi folks,

I'm writing to provide a little background about the src/mojo top-level directory that was recently added.

The README file says:

This is an effort to extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content, such as HTML, Pepper, or NaCL.

That sounds like a fairly lofty goal. What it really boils down to is isolating the components of our multi-process architecture that are concerned with process management, sandboxing and IPC. Much of this work is / will be straightforward extraction of code that is currently part of src/content/ into a narrower submodule.

In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:

  • The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.

  • Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.

  • We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.

  • The IPC system should make it easier to setup and pass around byte streams, shared memory and files. There is a bit of a barrier to using these things correctly in the current setup, which often results in people choosing less efficient methods of passing around data.

  • The IPC system should use a messaging format that is optionally capable of being used in cases where we want to talk between end-points built from different versions of the code base. This would open up the possibility of breaking Chrome up into components that are versioned separately. (Note: We already do this to a certain extent by leveraging Pepper, but growing Pepper for these use cases is costly if the APIs are not general purpose.)

  • Related to the above, we should have a binary pickling format that is more resilient to version skew. See the mess that is content/common/ for an example of how base::Pickle is not at all the right choice for archiving data structures.

The above is just a taste of some of the benefits to be had. More details as they emerge :-)