On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski <j...@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?
