2009/3/24 Thomas Van Lenten <thoma...@chromium.org> > A bunch of process handle code is something we're gonna need to look very > carefully at. The filtering via names may be valid on Windows, but on > Linux, a user could have Chromium running twice (with different > profiles/user data dirs) pointing at different displays, so we'll have to be > very careful to make sure it's only acting on the processes in the current > "instance" and not the other one. > > If I remember right when I looked at some of this, the Windows code uses > the process filter as a hook to scan the windows to find a running Chromium > and send it a message. So that whole functionality should be re-abstracted, > if needed, instead of making it have to work by walking a process list.
Right, this is used so that if the user starts Chrome a second time, it tells the currently running exe to open a new tab. This is the standard way of doing it on Windows, but I don't know how Mac/Linux apps enforce single-instance semantics. We should first figure out if this code is needed before porting it.. > > > TVL > > > > On Tue, Mar 24, 2009 at 11:31 AM, Paweł Hajdan Jr. < > phajdan...@chromium.org> wrote: > >> I'm thinking about porting chrome/common/chrome_process_filter, but I >> don't quite know how it works on Windows (there's some FindWindowEx there). >> Could someone briefly explain what it's supposed to do? >> >> And some more specific questions: >> >> - does it match only browser process, or everything (browser, renderer, >> etc)? >> - would ProcessSingleton be a good starting point for making the filter >> work on Linux? (like trying to see which process has the singleton socket >> open) >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---