Date: Wed, 31 May 2000 00:00:05 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Message-ID: <200005310700.AAA08578@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: Bruce Evans <bde@zeta.org.au>
To: Kelly Yancey <kbyanc@posi.net>
Cc: David Malone <dwmalone@maths.tcd.ie>,
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005310700.AAA08578>