From owner-freebsd-bugs Wed May 31 0: 0:13 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 DB87237BDB3 for ; Wed, 31 May 2000 00:00:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA08578; Wed, 31 May 2000 00:00:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 31 May 2000 00:00:05 -0700 (PDT) Message-Id: <200005310700.AAA08578@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Reply-To: Bruce Evans 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: Bruce Evans To: Kelly Yancey Cc: David Malone , freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Date: Wed, 31 May 2000 16:58:20 +1000 (EST) Everything that is implemented using itimers has this limit. The limit is only documented explicitly in setitimer.2, alarm.3 and ualarm.3. The possible existence of a limit is documented in select.2: [EINVAL] The specified time limit is invalid. One of its com- ponents is negative or too large. Saying exactly which values are too large in the man page wouldn't be very useful. Programs (sic) would have to read the man page to determine the limit, since it would be machine-dependent. A limit reported by sysconf(2) would be more useful, but there is no standard for this. 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 :-). On Tue, 30 May 2000, Kelly Yancey wrote: > On Tue, 30 May 2000, David Malone wrote: > > Here is what "The Single UNIX Specification, Version 2" that I > > downloaded about a year ago says: > > > > Implementations may place limitations on the maximum timeout > > interval supported. On all implementations, the maximum timeout > > interval supported will be at least 31 days. If the timeout Setting HZ to More than about 800 will break this. There are many possible problems like this, so nonstandard values of HZ aren't really supported. > > argument specifies a timeout interval greater than the > > implementation-dependent maximum value, the maximum value will be > > used as the actual timeout value. Implementations may also place > > limitations on the granularity of timeout intervals. If the > > requested timeout interval requires a finer granularity than the > > implementation supports, the actual timeout interval will be > > rounded up to the next supported value. > > > > So it looks the implimentation doesn't agree with this, and the > > man page should probably say what the max timeout is. > > > > (Excerpt is from http://www.opennc.org/onlinepubs/7908799/xsh/select.html). > > > > I read this to say that returning EINVAL (as reported in the submitted > PR) is the Wrong Thing and that we should be rounding the interval down > instead. The culprit is kern_time.c:itimerfix which is called by select, 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()). > So someone more wise will definately need to review this (simple) patch > as it may have far-reaching affects. It affects setitimer(), etc. The SUS requires setitimer() and alarm() to handle the full interval. POSIX requires this for alarm() IIRC. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message