From owner-freebsd-bugs Sun Jan 23 16:50: 9 2000 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 90225157CC for ; Sun, 23 Jan 2000 16:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA70780; Sun, 23 Jan 2000 16:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Sun, 23 Jan 2000 16:50:02 -0800 (PST) Message-Id: <200001240050.QAA70780@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Peter Jeremy Subject: Re: kern/13644 Reply-To: Peter Jeremy 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: Peter Jeremy To: Mikhail Teterin Cc: stable@FreeBSD.ORG, FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/13644 Date: Mon, 24 Jan 2000 11:43:41 +1100 On 2000-Jan-24 03:37:19 +1100, Mikhail Teterin wrote: >=> =FreeBSD: >=> ==> => If timeout is a non-nil pointer, it specifies a maximum >=> ==> => interval to wait for the selection to complete. ... >It appears, that you, as well as other developers, speak from the >implementation point of view. I only look at the man-page. The man page >says, the time out is the UPPER limit. Note that the man page talks about waiting for the _selection_ to complete. It does not refer to returning from the select(2) call. And the behaviour is exactly as documented: when the specified interval is complete, the process will return to the run queue for normal scheduling (if it hasn't previously found a ready FD). Unix is not a real-time OS, so once a process is in the run queue, an arbitrary period can expire before the process is actually run. The only cases where a select(2) (or poll(2)) system call will return before a specified period are: 1) A signal was received 2) One of the specified file descriptors became ready. >sorts of other man-pages from all sorts of other vendors, who all say >(almost) the same thing: > > that the timeout is indeed the UPPER limit, and not the LOWER. Please provide a test program and results from these other vendors demonstrating that their select() will return before the specified time limit in the absence of any other event. It's probably worthwhile adding a comment to select(2) similar to that in sleep(3), noting that "system activity may lengthen the sleep by an indeterminate amount." Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message