apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiyo Kelvin Lee <kiyo...@hotmail.com>
Subject apr/win32 misinterpreted the meaning of WAIT_ABANDONED
Date Mon, 31 Oct 2005 06:54:32 GMT
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


Mime
View raw message