GNU bug report logs - #77535
timeout treats very short durations as `0`

Previous Next

Full log

Message #31 received at 77535 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 77535 <at> debbugs.gnu.org
Cc: nicolas <at> boichat.ch
Subject: Re: bug#77535: timeout treats very short durations as `0`
Date: Sat, 5 Apr 2025 21:56:53 +0100

[Message part 1 (text/plain, inline)]

On 05/04/2025 12:03, Pádraig Brady wrote:
> On 05/04/2025 09:03, Paul Eggert wrote:
>> On 2025-04-04 12:27, Pádraig Brady wrote:
>>> +  /* Clamp underflow to 1ns, as 0 disables the timeout.  */
>>> +  if (duration == 0 && errno == ERANGE)
>>> +    duration = 1e-9;
>>
>> That isn't exactly right as the 1e-9 double-rounds to 2e-9 when we
>> compute the struct timespec. Also, even with the patch the code
>> mishandles 16777216.000000001 (2**24 + 10**-9) by treating it as if it
>> were just 16777216. These are tiny bugs, I know, but I took up the
>> challenge of doing this things more correctly by installing the attached.
> 
> This is the first time coreutils is linking with libm.
> So practically that does add measurable overhead:
> 
>     $ time seq 10000 | xargs -n1 src/timeout-old >/dev/null
>     real    0m7.139s
> 
>     $ time seq 10000 | xargs -n1 src/timeout >/dev/null
>     real    0m8.161s
> 
> So on my 2.6GHz i7-5600U we're adding 102,200 ns to the startup time,
> to address theoretical single nanosecond issues.
> Given the code is also more complex, I'm thinking using libm is not worth it?
> 
> BTW I'll apply the attached cleanups if we keep the libm dependency.

I'm going to apply the attached later to remove the libm dependency.
It's just too much of a dependency for minimal functionality.
All existing tests are maintained, and still pass.

cheers,
Pádraig

[timeout-remove-libm.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.