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>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506071724.DAA25128>