Date: Thu, 8 Jun 2000 01:40:03 -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: <200006080840.BAA25083@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: David Malone <dwmalone@maths.tcd.ie> Cc: Kelly Yancey <kbyanc@posi.net>, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds Date: Thu, 8 Jun 2000 18:31:18 +1000 (EST) On Wed, 7 Jun 2000, David Malone wrote: > > 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? I think it was intended. For both itimers and select(), the value of timeout()'s `tick' arg was once calculated using hzto(). This involved a timevaladd() of the current time to a timeout. It was important that the addition doesn't overflow. This was arranged by limiting the timeout. 32-bit signed time_t's will overflow in 2038, and timeouts of 10^8 would have started overflowing things in 2035. FreeBSD now uses tvtohz() instead of hzto(), so the limit of 10^8 is no longer very appropriate for either itimers or select(). A limit of (timeval when time_t's overflow) - (current time) would be about right. It would be better to have no limit until the current time actually overflows time_t (which won't happen becauase either time_t or the code will be changed before then), but this may require more changes to avoid overflow in intermediate computations. > 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. The first is enforced in various places. 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?200006080840.BAA25083>