apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c
Date Fri, 07 Apr 2017 08:21:14 GMT
On Fri, Apr 7, 2017 at 2:28 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Apr 6, 2017 3:34 PM, "Jim Jagielski" <jim@jagunet.com> wrote:
>
>
>> On Apr 6, 2017, at 4:25 PM, Jacob Champion <champion.p@gmail.com> wrote:
>>
>>>>>
>>
>> A zero or negative timeout should attempt to instantaneously acquire, and
>> return TIMEUP immediately if that's not possible. Treating negative values
>> the same way as zero allows client code to handle interval calculations in a
>> generic manner.
>>
>
> I can see the rationale for that... From an API PoV, that makes
> logical sense, I think.
>
>
> I agree, and also question the abs time logic. Why would we want to
> introduce an extra computational burden and logic  test in critical path
> code?  If the caller has an abs time they can perform the math in the most
> efficient manner possible, we must call out for the system time and have no
> means to optimize this.

I removed the abs handling in r1790488 and backported to 1.6, but
still timeout < 0 is INFINITE, timeout == 0 is IMMEDIATE, and timeout
> 0 is upper bound. This is consistent with
apr_thread_cond_timedwait() at least, and several underlying mutex
primitives that we use to implement timedlock...

Mime
View raw message