Reusing Chromium IPC library

[Anton Vayvod]

Hi,

I'm interested in reusing Chromium IPC code in a project which should work across all major platforms. I'm thinking about using code from src/ipc/ dir but have a couple of questions.

First, how stand-alone ipc/ code is? What does it use except for base/ maybe?

Second, why it uses sockets instead of named pipes on Linux (and I guess Mac as well)?

And lastly, one of the processes that needs to use IPC is GPL-licensed which I think means it can't be simply linked with Chromium codebase. Any thoughts on my options here?

Thanks,

Anton.

[Adam Langley]

On Nov 7, 2012 1:25 PM, "Anton Vayvod" <ava...@chromium.org> wrote:
>
> Hi,
>
> I'm interested in reusing Chromium IPC code in a project which should work across all major platforms. I'm thinking about using code from src/ipc/ dir but have a couple of questions.
>
> First, how stand-alone ipc/ code is? What does it use except for base/ maybe?
> Second, why it uses sockets instead of named pipes on Linux (and I guess Mac as well)?

Named UNIX domain sockets are resources that need to be cleaned up after use. By using unnamed sockets, the kernel will clean up for us when we crash. Additionally, we restrict filesystem access for renderers and so named sockets may be inaccessible to them.

Cheers

AGL

>
> And lastly, one of the processes that needs to use IPC is GPL-licensed which I think means it can't be simply linked with Chromium codebase. Any thoughts on my options here?
>
> Thanks,
> Anton.
>

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Scott Graham]

On Wed, Nov 7, 2012 at 10:24 AM, Anton Vayvod <ava...@chromium.org> wrote:
> Hi,
>
> I'm interested in reusing Chromium IPC code in a project which should work
> across all major platforms. I'm thinking about using code from src/ipc/ dir
> but have a couple of questions.
>
> First, how stand-alone ipc/ code is? What does it use except for base/
> maybe?

It only relies on base, but a standard build of base depends on a
variety of other things. You can get an idea from looking at
base/DEPS. base is not really intended/designed/supported to work
outside of a chromium build as a standalone project, which implies
ipc/ isn't either.

(I wrote a little script counter to this advice but only a quick hack
for windows: https://github.com/sgraham/crb You can see it's quite
ugly to do.)

(I don't know the answer to your other questions.)

> Second, why it uses sockets instead of named pipes on Linux (and I guess Mac
> as well)?
>
> And lastly, one of the processes that needs to use IPC is GPL-licensed which
> I think means it can't be simply linked with Chromium codebase. Any thoughts
> on my options here?
>
> Thanks,
> Anton.
>

[Antoine Labour]

On Wed, Nov 7, 2012 at 10:24 AM, Anton Vayvod <ava...@chromium.org> wrote:

Hi,

I'm interested in reusing Chromium IPC code in a project which should work across all major platforms. I'm thinking about using code from src/ipc/ dir but have a couple of questions.

First, how stand-alone ipc/ code is? What does it use except for base/ maybe?

According to ipc.gyp:

        '../base/base.gyp:base',

        '../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations',

So, base, pretty much (dynamic_annotations is required by base, essentially). 

Second, why it uses sockets instead of named pipes on Linux (and I guess Mac as well)?

And lastly, one of the processes that needs to use IPC is GPL-licensed which I think means it can't be simply linked with Chromium codebase. Any thoughts on my options here?

Check with your lawyer (obviously), but the license of chromium code (including IPC) is 3-clause BSD-style, which AFAIK is compatible with GPL.

Antoine

[Antoine Labour]

On Wed, Nov 7, 2012 at 10:47 AM, Antoine Labour <pi...@google.com> wrote:

On Wed, Nov 7, 2012 at 10:24 AM, Anton Vayvod <ava...@chromium.org> wrote:

Hi,

I'm interested in reusing Chromium IPC code in a project which should work across all major platforms. I'm thinking about using code from src/ipc/ dir but have a couple of questions.

First, how stand-alone ipc/ code is? What does it use except for base/ maybe?

According to ipc.gyp:

        '../base/base.gyp:base',

        '../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations',

So, base, pretty much (dynamic_annotations is required by base, essentially). 

And also, the implementation is slightly linked to chrome's use of it (check ipc/ipc_message_start.h), which means that if you want to have your own set of messages, you'll need to modify that file.

Antoine

[ClaudioJunior]

I am making use of chromium code for particular reason, and anything you want to make with chromium code you will need to have base together. Actually, base is the good portion of chromium with no match in C++ between the general-use libraries.

Building and linking base with your code is a no-brainer if you are using GYP for generating your projects.

Cheers.

[Jake]

And I use base standalone for a couple of projects. 

[Alexander Potapenko]

BTW one doesn't really need dynamic_annotations if he's not going to run TSan.

[ClaudioJunior]

Chromium code rocks as a library.

[William Chan (陈智昌)]

As said earlier, base/ is not designed to be used outside of Chromium projects. That is explicitly a non-goal.

That said, I'm very happy to hear it's working well for you guys :)

On Wed, Nov 7, 2012 at 11:36 AM, ClaudioJunior <claudio...@yahoo.com> wrote:

Chromium code rocks as a library.

--

[Levi Weintraub]

I'm sure it's out of date, and may not fit your use, but I can say that webOS actually used an extracted and modified version of Chromium's IPC code. It's open source as well and available here: https://github.com/openwebos/luna-sysmgr-ipc

[James Robinson]

Mozilla also has a copy that's even older still: http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/.  You have lots of company here even though this isn't a use case that is officially supported by the chromium project.  I've done exactly the same thing as well on a project a while back (in fact even before that I helped move ipc/ into its own top-level directory in part to make this easier).  You should just need ipc/, base/ and base/'s dependencies.

- James

[Alec Flett]

Hopefully this isn't heresy but I also have to recommend thrift (http://thrift.apache.org/) as a reasonable alternative - it's designed to be more standalone, and more cross-language.

If google had released the RPC side of ProtocolBuffers, I might have recommended that instead...

IMHO I've found the codegen aspect of both of these projects to be easier to work with than the set of macros that make up much of the chromium IPC code. At the very least with the above projects you don't have to fork an existing library and try to track changes that will come that may introduce unrelated chromium dependencies - plus these libraries are designed to handle IPC between clients that dont' necessarily have the same version of your IPC messages - something that is not a requirement for chromium IPC.

Alec

On Wed, Nov 7, 2012 at 10:24 AM, Anton Vayvod <ava...@chromium.org> wrote:

--

[Alexandre Elias]

Also, Thrift and Protocol Buffers are much more robust to version changes -- that's one of the main design goals of those systems.  So they are far superior to Chrome's IPC serialization for messages written to disk or sent across systems that are updated independently.

However, Chrome's IPCs are fine for their intended purpose of being sent across processes inside a single app.  I think the reason a separate system was developed was a timing problem where protocol buffers were not open-sourced yet when Chrome development started.

[Paweł Hajdan, Jr.]

On Wed, Nov 7, 2012 at 2:23 PM, Alexandre Elias <ael...@chromium.org> wrote:

However, Chrome's IPCs are fine for their intended purpose of being sent across processes inside a single app.  I think the reason a separate system was developed was a timing problem where protocol buffers were not open-sourced yet when Chrome development started.

I don't think that's the case. More likely the need to e.g. transfer Windows HANDLEs and UNIX file descriptors across the IPC channel, which AFAIK protobuf doesn't support.

Paweł

[ClaudioJunior]

The real upside of using a chromium code is that brings a lot of cool solutions. Furthermore, it promotes a good design of code. Somehow, Chromium's team discovered a way of developing C++ code that is efficient, easier and practical.

I mean, Boost, even STD are awkward and very complex. Chromium keeps the focus on efficient but with a better approach.

It may seem strong, but chromium's team is more competent than C++ committee standard, and should a structure like that be available more easily, C++ projects would be more productive and less expensive.

- Claudio.

[Anton Vayvod]

Thanks everyone for good advice and I agree that Chromium code maintaining very high quality in all aspects.

I found SyncSocket class in base/ library which seems to be sufficient to my needs. However, its design suggests that one process creates both sockets and then duplicates one of them for the remote process to use it. It seems to be used only by PepperBrokerImpl (using ipc/ to actually pass the duplicated handle to remote process).

Any pros/cons on using SyncSocket for basic IPC between processes and not depending on ipc/ ?

[Anton Vayvod]

+olilan

[Mark Mentovai]

I saw this thread a couple of weeks ago. I’ve experienced similar problems personally. When I’m working on non-Chrome code, I find myself reaching for the utilities in base. Worse, some of the code I’m working on, like Breakpad, is expected to work both as a part of Chrome and standalone. Making Chromium a dependency of other projects is a non-starter. Importing a copy of base into other projects means that all of these other projects will have their own local copies of the same code, and things get hairy when you try to use those other projects in Chromium again. Each library shouldn’t need to have its own local copy of base/logging.{h,cc}, either in source or binary form: when building as part of Chromium, it should be enough to just use Chromium’s copy.

For a little more than a year, I’ve been using something called mini_chromium for these projects. It’s essentially a scaled-back version of base that works as a standalone and exposes the same interfaces as Chromium’s base. It’s nowhere near complete: when I need something that’s missing from mini_chromium, I have to add it by hand. However, I’ve found that for the most part, there isn’t really that much change here over time. I tend to use scoped_ptr, StringPrintf, the StringToInt family, and the Mac-specific casts all over the place, for example. It only works on Mac and Linux (with a few extra utilities for Mac than Linux), but Scott’s crb seems to fill a simliar role for Windows. I don’t personally use Windows, so omitting it helped keep things lightweight.

I just cleaned up a few rough edges and published it on GitHub at https://github.com/mark-chromium/mini_chromium . Feel free to use it if you find it useful. I can’t promise anything about maintenance or adding base features that I don’t need outside of Chromium, but I do plan to keep it updated for the benefit of other projects I’m working on (such as Breakpad) that need to work both in and out of Chromium.