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