[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: 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. Ah, this is not at all the cleanup that I thought that you were proposing, but reasonable none the less. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
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? -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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
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.) TVL -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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher da...@chromium.org wrote: On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: 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? In order to wire up IPC::Channel on Unix, we must do something on the order of passing an fd retrieved from IPC::Channel to whatever it is which spawns the subprocess. Right now, the callers pulls the fd from the channel and passes it to LaunchApp(). So like casting to void*, the dependency is there, it's just not cleanly exposed. Another option I was thinking about over the weekend was to have the spawn code expose API for passing fds down to children (using a distinct socketpair per child), then IPC::Channel and base::SharedMemory could use that. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
+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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
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. 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 da...@chromium.org 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 sto...@google.com 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 5:12 PM, cpu c...@chromium.org 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 da...@chromium.org 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 sto...@google.com 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 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 -~--~~~~--~~--~--~---
