+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 <sh...@chromium.org> wrote:
>
> On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
> <thoma...@chromium.org> wrote:
>> On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher <da...@chromium.org> wrote:
>>> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess <sh...@chromium.org> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
