On Fri, Apr 7, 2017 at 11:07 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Fri, Apr 7, 2017 at 4:33 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> On Apr 7, 2017, at 9:53 AM, Branko Čibej <br...@apache.org> wrote: >>> >>> On 07.04.2017 14:38, Jim Jagielski wrote: >>>> You are assuming that the dev directly sets the timeout... what if it >>>> is calculated and somehow the calc'd time is negative. To me >>>> that means that it's "too late" and the expected result would >>>> be a timeout, >>> >>> Timeout iff the lock can't be immediately acquired, I'd say >> >> Again, I could see that as expected rather than "wait forever" :) > > How about: > #define APR_INFINITE_TIMEOUT APR_INT64_MIN > which could be handled by *_timed() functions, while the other > negative timeouts would mean immediate?
-1 if you are adding special-case logic/tests plus giving users a reason to call this API for a deliberate infinite timeout, they missed the point of the already existing API... keep it simple. We shouldn't explode the API in order to enforce mandatory application of TMTOWTDI, heh. Do we expect timeout values to exceed a half day? (apr_interval_time_t) Otherwise ++1 to your recent API simplification.
