On Tue, Mar 24, 2009 at 10:14 AM, Dan Kegel <[email protected]> wrote: > > 2009/3/24 John Abd-El-Malek <[email protected]>: >>> 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. > > FWIW, here's how iceweasel does it when using X: > > http://www.google.com/codesearch/p?hl=en#coP3VhWcvX0/widget/src/xremoteclient/XRemoteClient.cpp&q=XRemoteClient&exact_package=svn://svn.debian.org/pkg-mozilla/iceweasel/trunk&l=452 > > // Get a list of the children of the root window, walk the list > // looking for the best window that fits the criteria. > if (!XQueryTree(mDisplay, root, &root2, &parent, &kids, &nkids)) { > ... > } > > // We'll walk the list of windows looking for a window that best > // fits the criteria here. > > for (i=nkids-1; i >= 0; i--) { > Atom type; > int format; > unsigned long nitems, bytesafter; > unsigned char *data_return = 0; > Window w; > w = kids[i]; > // find the inner window with WM_STATE on it > w = CheckWindow(w); > > int status = XGetWindowProperty(mDisplay, w, mMozVersionAtom, > 0, (65536 / sizeof (long)), > False, XA_STRING, > &type, &format, &nitems, &bytesafter, > &data_return); > ... > > i.e. it doesn't look at processes at all.
(I wrote the ProcessSingleton stuff recently, so this is fresh in my memory...) The only reason we want to prevent multiple instances from running is to prevent database corruption. Therefore, the locking belongs alongside the database, on the file system. (This means you can't currently run the same profile as two processes on separate displays, which is kinda sad.) To answer the original questions: - The process singleton bits *don't* use BrowserProcessFilter. Though looking at the code it does appear to be a bit duplicated between ProcessSingleton's Windows implementation. For background, it seems Chromium (on Windows) creates an invisible window on startup that is used for sending messages between processes, and the FindWindowEx calls are used to find that window. - To port BrowserProcessFilter I'd look at its uses. It seems to only be used in testing code. In two instances it's for extracting data out of the stats table in a rather Windows-specific way. There's been a lot of talk about rearranging how the stats table stuff works but I don't think anyone's done it yet. agl suggests you could parse /proc/<pid>/maps to find the /dev/shm entry we're using, but I believe that might go away at some point (Dean?). Or you could imagine extracting the relevant stats a different way -- like maybe since we're already in the automation system you could just add an automation IPC for getting stats? Or even just have it output the relevant information to stdout and grab it via pipes? (I don't know this testing code at all.) I guess I may be just seconding Amanda's point, that it'd be best to skip the file in particular and instead make a higher-level wrapper around it. That's what I did in making ProcessSingleton. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
