On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov <himi...@gmail.com> wrote:
> 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_*.
Having seen the rest of the discussion now, I think a fair summary of this is:
1) On Windows, the existing code is cleaner (no extra pid file, cleans
itself up for free).
2) On Mac, they will use a different mechanism for process_singleton.
That still leaves:
- Linux process_singleton, process_util
- Mac process_util
The Linux process_singleton still needs the socket for being able to
send commands through (after your change, which I'd still like
commit), so it's unlikely to change.
That leaves process_util for Linux and Mac, which uses fuser (or
something similar) and that is a hack. However, it's only used for ui
tests, I believe -- it's not needed in normal usage. I am not opposed
to (lazily, on a background thread) writing a pid file on Linux,
though I'd prefer some other solution if one could be found. Maybe
it's to just remove the need for ChromeBrowserProcessId() somehow.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
