From owner-freebsd-bugs  Mon Dec 27 21:20:10 1999
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 47A2614D75
	for <freebsd-bugs@FreeBSD.org>; Mon, 27 Dec 1999 21:20:05 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id VAA92140;
	Mon, 27 Dec 1999 21:20:05 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Date: Mon, 27 Dec 1999 21:20:05 -0800 (PST)
Message-Id: <199912280520.VAA92140@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: Mikhail Teterin <mi@kot.ne.mediaone.net>
Subject: Re: kern/13644
Reply-To: Mikhail Teterin <mi@kot.ne.mediaone.net>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

The following reply was made to PR kern/13644; it has been noted by GNATS.

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
Date: Mon, 27 Dec 1999 23:49:28 -0500 (EST)

 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