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:37:47 GMT
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?


Mime
View raw message