On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten <[email protected]> wrote: > 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.)
It seems reasonable to me to distinguish launching an app to process a download from launching a renderer or plug-in process. We probably want to be pretty pedantic about the renderer process, and I'm very certain we don't want to rely on external services to deal with it (relying on Finder to launch renderer processes feels very uncomfortable to me). Due to the differences in process model between Unix and Windows, there may be bits which would be easier/cleaner/safer to setup in the parent process and inherited into the child versus passing parameters to the child and having it set things up (the bootstrap fd for IPC is one such thing). -scott --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
