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 <j...@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....@gmail.com> wrote: >> >> 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? >
