From owner-freebsd-bugs Mon Dec 27 21:20: 4 1999 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 0BF1514D75 for ; Mon, 27 Dec 1999 21:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA92126; Mon, 27 Dec 1999 21:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Mon, 27 Dec 1999 21:20:02 -0800 (PST) Message-Id: <199912280520.VAA92126@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/13644 Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/13644; it has been noted by GNATS. From: Bruce Evans To: Mikhail Teterin 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