Date: Sun, 23 Jan 2000 11:36:08 -0500 (EST) From: Mikhail Teterin <mi@kot.ne.mediaone.net> To: David Schwartz <davids@webmaster.com> Cc: Mikhail Teterin <mi@kot.ne.mediaone.net>, stable@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <200001231636.LAA43285@rtfm.newton> In-Reply-To: <000a01bf655e$314bb6c0$021d85d1@youwant.to> from David Schwartz at "Jan 22, 2000 08:56:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
David Schwartz once stated: => =FreeBSD: => ==> => If timeout is a non-nil pointer, it specifies a maximum => ==> => interval to wait for the selection to complete. = While the pthreads case is clearly a bug, in the other cases, =FreeBSD's behavior seems correct. The timeout is bounding the time we =wait for the selection to complete. However, the time to get back to =the task includes more than just the time spent waiting 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. The pthread case is broken even further... Bruce, it appeared, tried to say the man-page is broken, while the implementation is correct, but remains silent despite me quoting all 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. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001231636.LAA43285>