Date: Sun, 23 Jan 2000 12:10:55 -0800 From: Jason Evans <jasone@canonware.com> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: David Schwartz <davids@webmaster.com>, bde@freebsd.org, hackers@freebsd.org Subject: Re: kern/13644 Message-ID: <20000123121055.F27689@sturm.canonware.com> In-Reply-To: <200001231636.LAA43285@rtfm.newton>; from mi@kot.ne.mediaone.net on Sun, Jan 23, 2000 at 11:36:08AM -0500 References: <000a01bf655e$314bb6c0$021d85d1@youwant.to> <200001231636.LAA43285@rtfm.newton>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 23, 2000 at 11:36:08AM -0500, Mikhail Teterin wrote: > 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. I don't think this is "clearly a bug" in the pthreads case. > 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. I thought Bruce was pretty clear when he explained that such upper bounds are not possible unless the operating system can make hard real-time guarantees. FreeBSD is clearly not capable of hard real-time. If I remember correctly, neither are any of the operating systems from which you quoted man pages. That makes *all* of those man pages inaccurate. FreeBSD can put a process to sleep for a specified period of time, but it absolutely does not guarantee that the process will be run again precisely when the timeout has expired. In fact, as explained in earlier email, the timeout is rounded up in order to be certain that the process isn't woken up too early. Our man page is wrong: If timeout is a non-nil pointer, it specifies a maximum interval to wait for the selection to complete. This could perhaps be rewritten to say: If timeout is a non-nil pointer, it specifies a constrained lower bound on the maximum interval to wait for the selection to complete before again allowing the process to run. This reflects reality more closely, but I wouldn't argue for it being a better man page explanation of select() timeout semantics. If you can come up with some better wording that you can convince a committer is accurate and comprehensible, you might consider pursuing this issue. That's the only direction I have any interest in following this discussion in, however. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000123121055.F27689>