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?

-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
-~----------~----~----~----~------~----~------~--~---

Reply via email to