Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of trawick@gmail.com designates
 64.233.162.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=VwRshniuEH2vT0Vp+Fu/1GKxF3wY5TUpQSpX5268RKvHfK4w9REjLUCFA7qAWWqvKHZ84XKTlI1DCE+3IZ55QFFIJCdEf/drImcfh2bMMp1TzyIuvkKq4sXk/Oi0gVY+YreHBEEk6lPB8DuvQhqe3lb2BJxsRQjHkqOWMVxdK7E=
Message-ID: <cc67648e0602011014m78e7e5c9t809aed54fc5d3b6b@mail.gmail.com>
Date: Wed, 1 Feb 2006 13:14:44 -0500
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Subject: Re: One bug to close on win32; WAIT_ABANDONED
In-Reply-To: <43E0F717.4080904@rowe-clan.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43E0F717.4080904@rowe-clan.net>

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 thr=
ead
> has closed, and IIUC Win32 kernel will choose a new owner as a 'next step=
'.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=3D38410
>
> 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.