Re: FW: Bug#641832: bizarre behavior of timer_settime on kfbsd
On Fri, Sep 16, 2011 at 07:24:41PM +0200, Petr Salinger wrote:
If any debian-bsd people could add some insight to this one, it would be
appreciated.
I've tried various test values, and it doesn't require the time be
exactly MAX_INT to fail (smaller values fail also).
Please which one ?
The 49711 days really overflows.
The code rounds anything more than MAX_INT down to MAX_INT. Below that
value, the input is used. So, e.g.,
mstone@kfbsd:/tmp/coreutils-8.13/src$ ./timeout 2147483650 true; echo $?
124
uses 2147483647.999999999 as the timeout value,
mstone@kfbsd:/tmp/coreutils-8.13/src$ ./timeout 2147483647 true; echo $?
0
uses 2147483647.0 as the timeout value,
mstone@kfbsd:/tmp/coreutils-8.13/src$ ./timeout 2147483641 true; echo $?
124
uses 2147483641.0 as the timeout value.
Note that only the middle one behaved properly, and it will randomly
fail on subsequent runs. Much smaller (order of magnitude) numbers seem
ok, and I haven't identified a specific bad number. In a loop, 800000000
seems ok, while 900000000 exhibits intermittant failure. Assuming that
holds true, we could set the max timeout to about 25 years (which should
suffice for any practical purpose), but that seems like an odd value to
choose unless it can be somehow explained and rationalized.
The prior version of timeout didn't use setitimer, and one fix would be
to ignore that function when building on kFreeBSD, but that would mean
the program would have different features depending on which Debian
platform it's running on.
There are three variants of "timers".
- alarm - used in coreutils 8.5
- setitimer/getitimer
- timer_create/timer_settime - used in coreutils 8.13
Gah, I did mean timer_settime; my eyes are starting to cross on anything
timer related. :-)
alarm - only sends SIGALRM, single second resolution
setitimer - only sends SIGALRM, microsecond resolution
timer_create - can even start a thread, nanosecond resolution
IMHO, for mean time, the best way should be to use setitimer under
kFreeBSD, the timer_create is implemented (may be even buggy) in
certainly seems buggy. :-) even if this is papered over in coreutils,
how does it potentially affect other programs?
userspace and in fact its real precision is lower compared to
setitimer syscall.
Would be a setitimer patch acceptable for you ?
I don't particularly care, except that I'd prefer not to have a
debian-specific patch. The source has this note:
/* timer_settime() provides potentially nanosecond resolution.
setitimer() is more portable (to Darwin for example),
but only provides microsecond resolution and thus is
a little more awkward to use with timespecs, as well as being
deprecated by POSIX. Instead we fallback to single second
resolution provided by alarm(). */
so I'm not sure how it would be received upstream.
Mike Stone
Reply to: