Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of ylavic.dev@gmail.com designates
 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKQ1sVMGx6F_sVCwswD9PbgcHCg5sJm1M=iFE50Qr_dh7ebAsQ@mail.gmail.com>
References: <54295C2F.80307@lenk.info>
	<CAKQ1sVMGx6F_sVCwswD9PbgcHCg5sJm1M=iFE50Qr_dh7ebAsQ@mail.gmail.com>
Date: Tue, 30 Sep 2014 18:16:16 +0200
Message-ID: 
 <CAKQ1sVPS8Z-g0NXvZDRPhEW5bhWr3XgDp9ivUe-cA_5pw96-Ew@mail.gmail.com>
Subject: Re: How to wait on a global lock with timeout
From: Yann Ylavic <ylavic.dev@gmail.com>
To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 30, 2014 at 5:30 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> I have been working on a patch to provide
> apr_[thread/proc]_mutex_timedlock() in APR, but did not finish the
> work mostly because of APR_ENOTIMPL on some mutex mechanisms (mainly
> Windows CRITICAL_SECTIONs which lack the functionality, making the APR
> abstraction quite useless IMO, or at least unix specific). Maybe I'll
> have a new look at it these days if I have the time to.

Hmm, this remark about Windows only concerns thread-mutexes,
proc-mutexes don't use a CRITICAL_SECTION but a HANDLE (which is then
usable with WaitForSingleObject() that accepts a timeout).

I think I'll give my patch a new chance, at least for proc-mutexes
(and hence global-mutexes), but this is not a today's solution in any
case since I would be at best an APR-1.6 feature (if accepted)...