apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c
Date Thu, 06 Apr 2017 20:25:34 GMT
>>> On Wed, Apr 5, 2017 at 7:45 PM, Jim Jagielski <jim@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 <jim@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.


View raw message