apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c
Date Wed, 05 Apr 2017 17:45:27 GMT
In fact, that goes for all, really. All *.timedacquire() impl
should return APR_TIMEUP for any timeout < 0. Instead we
try to acquire which is against the whole ABI guarantee.

> On Apr 5, 2017, at 1:37 PM, Jim Jagielski <jim@jaguNET.com> wrote:
> If the timeout has expired, shouldn't we return APR_TIMEUP?
>> On Apr 5, 2017, at 1:25 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>> On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>> Your log is:
>>>  Follow up to r1667900: semtimedop() should be passed a relative timeout rather
>>>  then absolute.
>>> which implies that this fix is to adjust the calling convention for
>>> semtimedop()... but your code refers to proc_mutex_sysv_tryacquire()...
>>> Hope that makes it clearer.
>> APR_DECLARE(apr_status_t) apr_proc_mutex_timedlock(apr_proc_mutex_t *mutex,
>>                                                  apr_time_t timeout,
>>                                                  int absolute);
>> So the API allows the caller to specify whether the passed in timeout
>> value is absolute or relative (to now).
>> So depending on the underlying/native timedlock function, we have to
>> switch from the one to the other before the syscall.
>> semtimedop() expects a relative timeout, so if the caller gives an
>> absolute one we make it relative (by substracting now), and if the
>> result is negative (i.e. the given absolute time is the the past), we
>> act return of a non-blocking trylock
>> Why isn't it correct, should we error out or block indefinitely?

View raw message