On Fri, Apr 24, 2009 at 4:55 PM, Никита Офицеров <[email protected]> wrote:
> > There are now different platform-dependent ways to ensure that only > one instance of Chrome is running, and to get its pid. > I think that there is a way of accomplishing both goals in a > cross-platform way, reusing existing IPC system. > I'll try to explain how IMO things are now, and why this might be not > the best way: > > Now: > 1. Windows > Hidden top-level window is used for getting Chrome pid and IPC on > startup. This is actually reinventing IPC over window messages with > custom protocol. > 2. Linux > UNIX socket is used for IPC on startup, and fuser program is launched > on it to get the pid - IMHO not the best way to do it. > 3. Mac > There is now ProcessSingleton on Mac, as it's not needed. Some hack on > ps output is used to get the pid. > > So there are 3 different implementations, and not very optimal ones. > > Same effect could be acieved by this method: > Don't try to get pid dynamically, but create on startup in datadir > file 'ChromePid' or something like that with pid. Also, create an IPC > channel with channel_id equal to pid with forced FIFO mode on POSIX. > Current POSIX implementation should be modified to allow this and to > store socket in datadir, not in /var/tmp. Then ProcessSingleton check > would be simple and crossplatform: find pid file, read pid, connect to > channel, send some message and wait for response. > > This eliminates all differences between platforms in > process_singleton_* and chrome_process_util_*. > What do you think? I think the first question is what do we need/usr singleton for? Rather than ensure it's the same/common/etc. on all platform, it seems like a case where stepping further back and seeing why it's used might be more important. For the cases where it's used to handle off shortcut urls to an always running instance, that's not needed on the Mac as Launch Services already does that. I don't know, but there might be better ways on Linux for dealing this this the the current Windows model. I believe the unittests use it to see if something is already running with a given profile, a slightly different need. Cleaning up the calling places to have specifically defined needs might not result is needing what we have right now, but some different apis instead. TVL > > Nikita Ofitserov > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
