On Wed, Apr 5, 2017 at 9:53 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> On Apr 5, 2017, at 2:03 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> On Wed, Apr 5, 2017 at 7:45 PM, Jim Jagielski <j...@jagunet.com> wrote: >>> 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. >> >> I don't get it, why for a relative timeout, negative wouldn't mean >> infinite (like with poll() or several system calls), zero mean >> try-only, and positive a real timeout? > > Well, the thing is that we have an "infinite" variant of all > of them: the simple acquire... It seems to me the whole idea > of timeouts is, well, to honor the timeout value, and a > negative or 0 value means "it's past". Also recall that in > most cases, a "timeout" value is unsigned, making these > kinds of discussions moot. If people want a "just try" or > "infinite" they should use the correct and respective > actual functions and not overload and/or misuse timeouts...
I see, but it may also be convenient for a user to have a single apr_*mutex_timedlock() call somewhere, say in a helper or callback which always takes a timeout argument (rather than having to define two helpers or callbacks). If a negative timeout would simply return APR_TIMEUP (without even trying an acquire), what would be the point to specify one? > > all IMHO and my 2c Same here, feedbacks always welcome ;)
