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

Previous Next

Full log

Message #19 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 12:03:49 +0100

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

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.

cheers,
Pádraig

[timeout-round-tweaks.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.