On Wed, Feb 4, 2009 at 5: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.
Doesn't the code call LaunchApp if the window build isn't in the sandbox? It looks like that else path has a OS_WIN check at the moment because it's using the single string launch call that is windows only at the moment, but the intent seems to be to have LaunchApp work (atleast to support no sandbox mode). TVL > > 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 -~----------~----~----~----~------~----~------~--~---
