Date: Wed, 7 Jun 2000 14:40:01 -0700 (PDT) From: David Malone <dwmalone@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Message-ID: <200006072140.OAA90642@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/18909; it has been noted by GNATS.
From: David Malone <dwmalone@maths.tcd.ie>
To: Bruce Evans <bde@zeta.org.au>
Cc: Kelly Yancey <kbyanc@posi.net>, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds
Date: Wed, 07 Jun 2000 22:37:57 +0100
> Everything that is implemented using itimers has this limit. The limit
> is only documented explicitly in setitimer.2, alarm.3 and ualarm.3.
Unless I'm mistaken, select (and poll and the kevent stuff) don't
actually have anything to do with itimers, as the implementation
of their timeouts is with tsleep, which uses timeout, which uses
callouts. They are just borrowing the itimerfix() function for
a use for which it wasn't intended?
Probably what is needed is a timevalisvalid() function. There is
already a (static) timevalfix() function, however it doesn't do
what is required here.
> The limit of 10^8 seconds is imposed to reduce the chance of overflows
> in computations involving itimers. Note that timeouts of 10^8 seconds
> don't actually work, at least for select(). 10^8 seconds is 1157+
> days, by the default configuration of HZ = 100, timeouts in 32-bit
> ticks are limited to only 248+ days. If you increase HZ to 10^5 then
> you may even notice this bug :-).
I guess this means that itimerfix should really say something like:
- if (tv->tv_sec < 0 || tv->tv_sec > 100000000 ||
+ if (tv->tv_sec < 0 || tv->tv_sec/hz > 1000000 ||
tv->tv_usec < 0 || tv->tv_usec >= 1000000)
to avoid problems on such systems?
> I read this as a bug in the SUS :-). The easiest workaround is to not
> have a limit. It seems to be easy to fix for select() and poll(), since
> there is already a loop where we check after some wakeups to see if the
> timeout expired (see old fixes for this problem in nanosleep()).
> It affects setitimer(), etc. The SUS requires setitimer() and alarm() to
> handle the full interval. POSIX requires this for alarm() IIRC.
I'd be interested in trying to fix this, and really just need more
info on how timevals should be handeled. Is adding a timevalisvalid()
function/macro reasonable? How should negative timevals be represented?
Is -1.5s written as:
tv_sec = -2; tv_usec = 500000;
or tv_sec = -1; tv_usec = -500000;
I'd presume it is the first, but you never can tell.
David.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006072140.OAA90642>