I still don't like the idea of <0 == infinite, but I'm too tired to discuss it anymore :)
What this means, of course, is that instead of using the correct function calls for each situation, (acquire(), tryacquire(),) people instead will use the overloaded timedstuff, which to me is bad API. We are creating these from scratch, not adding additional functionality to something that already exists. :/ > On Apr 7, 2017, at 4:21 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > 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...
