On Fri, Apr 7, 2017 at 2:28 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Apr 6, 2017 3:34 PM, "Jim Jagielski" <j...@jagunet.com> wrote: > > >> On Apr 6, 2017, at 4:25 PM, Jacob Champion <champio...@gmail.com> wrote: >> >>>>> >> >> A zero or negative timeout should attempt to instantaneously acquire, and >> return TIMEUP immediately if that's not possible. Treating negative values >> the same way as zero allows client code to handle interval calculations in a >> generic manner. >> > > I can see the rationale for that... From an API PoV, that makes > logical sense, I think. > > > I agree, and also question the abs time logic. Why would we want to > introduce an extra computational burden and logic test in critical path > code? If the caller has an abs time they can perform the math in the most > efficient manner possible, we must call out for the system time and have no > means to optimize this.
I removed the abs handling in r1790488 and backported to 1.6, but still timeout < 0 is INFINITE, timeout == 0 is IMMEDIATE, and timeout > 0 is upper bound. This is consistent with apr_thread_cond_timedwait() at least, and several underlying mutex primitives that we use to implement timedlock...
