From owner-freebsd-bugs Thu Jun 8 1:40: 4 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 D373C37B55F for ; Thu, 8 Jun 2000 01:40:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA25083; Thu, 8 Jun 2000 01:40:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 8 Jun 2000 01:40:03 -0700 (PDT) Message-Id: <200006080840.BAA25083@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: David Malone Cc: Kelly Yancey , 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