Date: Sun, 23 Jan 2000 16:50:02 -0800 (PST) From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/13644 Message-ID: <200001240050.QAA70780@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: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Mikhail Teterin <mi@kot.ne.mediaone.net> 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 <mi@kot.ne.mediaone.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001240050.QAA70780>