From owner-freebsd-hackers Wed Jun 7 10:25:42 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA26584 for hackers-outgoing; Wed, 7 Jun 1995 10:25:42 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA26578 for ; Wed, 7 Jun 1995 10:25:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA25128; Thu, 8 Jun 1995 03:24:20 +1000 Date: Thu, 8 Jun 1995 03:24:20 +1000 From: Bruce Evans Message-Id: <199506071724.DAA25128@godzilla.zeta.org.au> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu Subject: Re: Interval timer/System clock Sender: hackers-owner@FreeBSD.ORG Precedence: bulk >The select man page says: > If timeout is a non-nil pointer, it specifies a maximum interval to wait ^^^^^^^ > for the selection to complete. If timeout is a nil pointer, the select > blocks indefinitely. To affect a poll, the timeout argument should be > non-nil, pointing to a zero-valued timeval structure. The wording is interesting. A maximum interval of course can't be guaranteed, To avoid waiting more than the maximum, the system could round the interval down. I don't know how far to trust this man page. Rounding the interval down to 0 is the best way to always wait less than the maximum. The setitimer man page says: Time values smaller than the resolution of the system clock are rounded up to this resolution. ^^ So select() must round in the opposite direction to setitimer()?! hzto() rounds up so select() shouldn't use it. The usleep man page says: System activity or time spent in processing the call may lengthen the sleep slightly. The sleep man page says: System activity or time spent in processing the call may lengthen the sleep by a second. [Was resolution once that bad? Is lengthening the sleep by anything other than a second allowed? :-)] The POSIX sleep spec is much clearer: ... the current process [shall be] suspended ... until either the number of real-tine seconds specified by the argument `seconds' have elapsed or a signal is delivered ... The suspension time may be longer than requested due to the scheduling of other activity ... [It doesn't explicitly allow it to be longer for other reasons!] >I would add a comment here about the wait interval to select. Something like: > The wait interval is determined by the system clock. Timeout values > are rouned up to the resolution of this clock (typically 10 > milliseconds). A wait interval of 10ms will usually wait > between 10 and 20ms on a FreeBSD system, a wait interval of 20ms > will wait between 20 and 30ms. This behavior is currently inconsistant > with other Unix systems where the wait interval may fall between > 0 and 10ms and 10 and 20ms respectively. I don't like to document the dependence on the system clock, since that is an implementation detail and will change when someone improves the resolution of the timeouts. Bruce