Date: Thu, 8 Jun 1995 03:24:20 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu Subject: Re: Interval timer/System clock Message-ID: <199506071724.DAA25128@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506071724.DAA25128>