Hmm, OK, I'll dig further. If ProcessUtil is anyhow not appropriate, then it probably doesn't make sense to rewire it before looking at how real renderers would be spawned.
-scott On Wed, Feb 4, 2009 at 2:12 PM, cpu <[email protected]> wrote: > > We don't launch renderers using LaunchApp, we use broker_service- >>SpawnTarget(). I guess in other platforms that don't have a sandbox > you can replace that for whatever you want. > > You can see BrowserRenderProcessHost::Init() for all the cruft that we > need to launch a renderer, I don't see a good way to move many of > these things down to \base. > > I think your best bet is to create an abstract method in > RenderProcessHost or such. > > Is anybody working on the Mac Sandbox? > > > > > On Feb 4, 12:47 pm, Darin Fisher <[email protected]> wrote: >> We talked about moving IPC out of chrome/common, but we should really only >> do that if we have a consumer. Right now, it is only needed by Chrome, so >> it would seem to be a "premature optimization" to spend time moving it >> elsewhere. >> -Darin >> >> On Wed, Feb 4, 2009 at 12:35 PM, stoyan <[email protected]> wrote: >> > +1 for Renderer/PluginLauncher() >> > +1 for moving IPC out of /chrome/common, in very own library. >> >> > Stoyan >> >> > On Wed, Feb 4, 2009 at 11:30 AM, Scott Hess <[email protected]> wrote: >> >> > > 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 -~----------~----~----~----~------~----~------~--~---
