apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c
Date Wed, 05 Apr 2017 20:23:48 GMT
On Wed, Apr 5, 2017 at 9:53 PM, Jim Jagielski <jim@jagunet.com> wrote:
>> On Apr 5, 2017, at 2:03 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>> 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.
>> 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 ;)

View raw message