On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher <[email protected]> wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess <[email protected]> wrote: > >> >> [Reposting from wrong mailing list, sorry for dupe.] >> >> 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? > Just for reference, I'm still sorting things out here, but on the Mac, we might want to actually bounce some of these launches through LaunchServices so the app think it was launched from the Dock/Finder/by the user and avoid it inherriting fds, mach info, etc. (I realize the renderers might need this, so we might end up w/ >1 launch api so we can get different "style" of launches, the current api seems to be mangled/extended w/ a collection of args to sorta cover different needs.) TVL > -Darin > > > >> >> The appropriate endpoint would not be marked close-on-exec, and would >> be passed down to the child via a new command-line parameter (versus >> the current static location). This could pretty easily be expanded to >> pass through multiple channels and make the new command-line parameter >> have multiple values, if we need to go there. Once we can pass fds >> over channels, that may be immaterial. From there, the Windows code >> could be adjusted to use the create-channel-spawn-process ordering to >> match, and the calling points would hopefully become less forked. >> >> Adam mentioned on the wrong-mailing-list version of this thread that >> it's accepted to wire file descriptors into fixed places. Either way, >> my goal is to make sure that launching Chrome-internal helper tasks is >> distinct from launching arbitrary tasks, because the Chrome-internal >> case most likely wants to make special provisions WRT the child, and >> right now that seems to be in the calling code. >> >> -scott >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
