I am a bit surprised to find that APR interpreted WAIT_ABANDONED as
equivalent to WAIT_OBJECT_0. See apr_proc_mutex_lock() and
apr_proc_mutex_trylock().
I believe this is wrong. According to doco from MS, WAIT_ABANDONED only
means the ownership of the mutex has been changed. The mutex is remain
**non-signaled** (or becomes so if it was signaled), i.e. while one
thread get the return code WAIT_ABANDONED, it is possible that another
thread would get the mutex signaled instead. So we can't simple return
APR_SUCCESS as described in this notes in the CHANGES file:
*) Win32: apr_proc_mutex_trylock and apr_proc_mutex_lock were
incorrectly returning APR_BUSY if the lock was previously
held by a thread that exited before releasing the lock
(ie, if the process holding the lock segfaults). The MSDN
doc says when WaitForSingleObject returns WAIT_ABANDONED,
the calling thread takes ownership of the mutex, so these
two routines should return APR_SUCCESS in this case, not
APR_BUSY. [Bill Stoddard]
However, we shouldn't return APR_BUSY either.
The normal proper way to handle WAIT_ABANDONED is to put the
WaitForSingleObject() (or any other equivalent API) in a loop, e.g.:
do {
rc = WaitForSingleObject(mutex, INFINITE);
} while (rc == WAIT_ABANDONED);
Regards,
Kiyo
