Date: Mon, 27 Dec 1999 23:49:28 -0500 (EST) From: Mikhail Teterin <mi@kot.ne.mediaone.net> To: Bruce Evans <bde@zeta.org.au> Cc: jasone@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, FreeBSD-gnats-submit@FreeBSD.ORG, lawlopez@cisco.com, jseger@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <199912280449.XAA78153@rtfm.newton> In-Reply-To: <Pine.BSF.4.10.9912281450300.9333-100000@alphplex.bde.org> from Bruce Evans at "Dec 28, 1999 03:18:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans once stated: =On Mon, 27 Dec 1999, Mikhail Teterin wrote: = => jasone@FreeBSD.ORG once stated: = => =select() guarantees that it will sleep at least as long as the timeout => =before returning an empty result (0). => => This is NOT what the man page states: => => If timeout is a non-nil pointer, it specifies a maximum => interval to wait for the selection to complete. = =This is a bug in the man page. It is so poorly worded that it is =broken. The Solaris man-page says the same (man -s 3c select): If timeout is not a NULL pointer, it specifies a maximum interval to wait for the selection to complete. And Linux (man 2 select): timeout is an upper bound on the amount of time elapsed before select returns. Are both of them wrong too?.. I'm sure TCL developers saw more selects then me, and they only account for the possibility of an _earlier_ return from select. => =If the number of ticks passed to tsleep() were reduced by one, this => =guarantee would no longer be possible. => = => =This is not a bug; it is an artifact of correct implementation. If => =you need higher resolution, use nanosleep(). = =There seems to be a problem with both the pthread and the kernel adding =one tick. Yes... With all due respect, IMHO, this PR should be re-opened. -mi 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?199912280449.XAA78153>