From owner-freebsd-bugs Wed Jun 7 14:40: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7699D37B6A6 for ; Wed, 7 Jun 2000 14:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA90642; Wed, 7 Jun 2000 14:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 7 Jun 2000 14:40:01 -0700 (PDT) Message-Id: <200006072140.OAA90642@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: David Malone Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Reply-To: David Malone Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/18909; it has been noted by GNATS. From: David Malone To: Bruce Evans Cc: Kelly Yancey , 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