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 Wed, 05 Apr 2017 17:25:02 GMT
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