apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: One bug to close on win32; WAIT_ABANDONED
Date Wed, 01 Feb 2006 18:14:44 GMT
On 2/1/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> WAIT_ABANDONED, according to these notes, is a signal that the owning thread
> has closed, and IIUC Win32 kernel will choose a new owner as a 'next step'.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38410
>
> What happens on unix when the owner 'dies'?

in general: kernel picks a new owner unbeknownst to us:

exception: with cross-process pthread mutexes, the ownership is toast
forever and ever, thus waiters on the mutex are hung

exception to exception: with cross-process pthread mutexes on Solaris
8 and above, APR uses a non-portable API which results in another
thread seeing a non-portable return code, and then APR does the magic
handshake with the kernel and returns APR_SUCCESS to the caller

> Can we map this to some consistent results from the apr call to >apr_proc_mutex_[try]lock()?

If the caller's explanation of WAIT_ABANDONED is correct, then the
caller's suggested loop looks good for apr_proc_mutex_lock().

I didn't realize there was apr_proc_mtuex_try_lock().  That should
return the didn't-get-the-lock retcode.

Mime
View raw message