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 -~----------~----~----~----~------~----~------~--~---