On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher <da...@chromium.org> wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess <sh...@chromium.org> wrote:
>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
>> pipes), with one end passed through the spawn to the child process.
>> Right now the interfaces don't expose this dependency, so I'm thinking
>> of refactoring things a bit to do so. Jeremy suggested that I talk to
>> Carlos, and I know tvl is looking at this - anyone else want in?
>>
>> Basic notion would be to modify LaunchApp() (or whatever Tom is doing
>> to it) to accept an IPC::Channel (versus the current vector of fds).
>
> LaunchApp is in base/, but IPC::Channel is in chrome/common/. You can't
> have base/ depend on chrome/common/, so if this dependency is the right
> answer, then we'd need to move IPC::Channel down to base/.
> Why is passing an IPC::Channel to LaunchApp the answer?
In order to wire up IPC::Channel on Unix, we must do something on the
order of passing an fd retrieved from IPC::Channel to whatever it is
which spawns the subprocess. Right now, the callers pulls the fd from
the channel and passes it to LaunchApp(). So like casting to void*,
the dependency is there, it's just not cleanly exposed.
Another option I was thinking about over the weekend was to have the
spawn code expose API for passing fds down to children (using a
distinct socketpair per child), then IPC::Channel and
base::SharedMemory could use that.
-scott
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
