Date: Mon, 27 Dec 1999 21:20:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/13644 Message-ID: <199912280520.VAA92126@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/13644; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: jasone@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, FreeBSD-gnats-submit@FreeBSD.ORG, lawlopez@cisco.com, jseger@FreeBSD.ORG Subject: Re: kern/13644 Date: Tue, 28 Dec 1999 15:18:25 +1100 (EST) On Mon, 27 Dec 1999, Mikhail Teterin wrote: > jasone@FreeBSD.ORG once stated: > =select() guarantees that it will sleep at least as long as the timeout > =before returning an empty result (0). > > This is NOT what the man page states: > > If timeout is a non-nil pointer, it specifies a maximum > interval to wait for the selection to complete. This is a bug in the man page. It is so poorly worded that it is broken. "maximum" here means "minimum" in the case where no selected event occurs. Returning before the specified interval has elapsed would not be useful, so the system "waits" until it has elapsed and then returns to the application at a convenient later time. Some related man pages, e.g., FreeBSD's setitimer(2) and The Single Unix Spec's select(2) clarify this a little by saying that the requested timeout may be rounded up to an implementation-defined next-supported value. > > =If the number of ticks passed to tsleep() were reduced by one, this > =guarantee would no longer be possible. > = > =This is not a bug; it is an artifact of correct implementation. If you > =need higher resolution, use nanosleep(). There seems to be a problem with both the pthread and the kernel adding one tick. 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?199912280520.VAA92126>