Re: crash in mswindows_need_event because of WAIT_TIMEOUT again
Mike Alexander wrote:
> This crash is, in my opinion, going to be hard to fix. It is
> a race condition if a subprocess goes away at about the same
> time mswindows_need_event is called. The handle for the
> subprocess may be in the vector of things it waits on even
> though the subprocess is gone. The only real way to fix this
...
After thinking about this some more, I don't think we can fix it
even by making a critical section of mswindows_need_event and
the code that manipulates mswindows_waitable_handles. Even if
we know the list of handles is valid immediately before the call
to MsgWaitForMultipleObjects, it might contain an stale handle
But the handle
isn't "stale" - under Windows, process handles
(as opposed to file handles, AFAIK) are handled the correct Unix
way - they are still valid after the process ends, *and* they
become "signaled", i.e. all waits on them are immediately
satisfied. In fact, ending the process is the only way to make a process
handle signaled... IMHO your patch is on the right track,
but if I were you, I'd look up MsgWaitForMultipleObjects & friends
in MSDN - waiting semantics under Windows really isn't something
I know by heart...
by the time the operating system gets around to looking at it.
That's probably why there is a specific return code for this
The specific
return code is for a mutex handle, AFAIK...
Bye
Vasek