Greatly reduce the race window in ProcessSingleton...

Greatly reduce the race window in ProcessSingleton
- fix only for windows
- Anantha has a good test to be commited RSN

BUG=9593
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=13313

[M-A Ruel, 2009-04-01 12:43:48]

lgtm but in fact, the race window could be completely eliminated by preemptively
creating the window and _then_ look for another window, which in that case the
window_ shall be destroyed. It would slightly slow down the process startup for
chrome.exe browser startup when a chrome window is already started. There is
still a slim chance that a third process starts at the same time and gets the
wrong remote_window_... What do you think?

[cpu_(ooo_6.6-7.5), 2009-04-01 17:56:33]

On 2009/04/01 12:43:48, M-A wrote:
> lgtm but in fact, the race window could be completely eliminated by
preemptively
> creating the window and _then_ look for another window, which in that case the
> window_ shall be destroyed. It would slightly slow down the process startup
for
> chrome.exe browser startup when a chrome window is already started. There is
> still a slim chance that a third process starts at the same time and gets the
> wrong remote_window_... What do you think?

I am not sure what is the scheme you are thinking of. If both processes create a
window then each one get a different window, when they call FindWindow() they
will get their window or the other process window, say we put that in a loop so
you get all both window handles, now both processes now know there is another
process and both proceed to destroy their window, which takes us to step 0.

You need a more complex, (multi-round?) protocol. Is that what you are thinking
about or this is april's fool comment?

[M-A Ruel, 2009-04-01 18:08:52]

lgtm :)