On 2000-Jan-24 03:37:19 +1100, Mikhail Teterin <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
