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