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 Fri, 07 Apr 2017 16:07:33 GMT
On Fri, Apr 7, 2017 at 4:33 PM, Jim Jagielski <jim@jagunet.com> wrote:
>
>> On Apr 7, 2017, at 9:53 AM, Branko ─îibej <brane@apache.org> wrote:
>>
>> On 07.04.2017 14:38, Jim Jagielski wrote:
>>> You are assuming that the dev directly sets the timeout... what if it
>>> is calculated and somehow the calc'd time is negative. To me
>>> that means that it's "too late" and the expected result would
>>> be a timeout,
>>
>> Timeout iff the lock can't be immediately acquired, I'd say
>
> Again, I could see that as expected rather than "wait forever" :)

How about:
#define APR_INFINITE_TIMEOUT APR_INT64_MIN
which could be handled by *_timed() functions, while the other
negative timeouts would mean immediate?

A user is quite unlikely to insist in a loop decreasing timeout until
APR_INT64_MIN...

Mime
View raw message