[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).
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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
