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.
If you're trying to match the pthreads API, you shouldn't return TIMEUP
*if* the mutex can be immediately acquired, even if the timeout is
negative. For a locking API, I think that makes sense -- the entire
point of a timedwait is to put an upper bound on the amount of time that
you could spend doing nothing.
On 04/05/2017 01:23 PM, Yann Ylavic wrote:
> On Wed, Apr 5, 2017 at 9:53 PM, Jim Jagielski <j...@jagunet.com> wrote:
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'm with Jim here; I don't think this behavior makes sense API-wise.
Passing an absolute timeout of zero (that is, "wait until the 1970
epoch") would return APR_TIMEUP, but passing an absolute timeout of -1
(one microsecond before the epoch) would wait forever. What?
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).
I've used the "negative waits forever" special case when writing
select() loops, which (I think) is what you're emulating. But I think
combining that special case with an absolute timeout flag, especially
for a locking API, is asking for trouble. Keep it simple, IMO; select()
is a different tool than a lock.
If a negative timeout would simply return APR_TIMEUP (without even
trying an acquire), what would be the point to specify one?
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.
--Jacob
