How is now an int? Wouldn't that be an apr_time_t (much too big to fit in an int on an LP64 arch.)
On Apr 5, 2017 12: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? >
