From owner-freebsd-stable Sun Jan 23 11:48:39 2000 Delivered-To: freebsd-stable@freebsd.org Received: from queeg.ludd.luth.se (queeg.ludd.luth.se [130.240.16.109]) by hub.freebsd.org (Postfix) with ESMTP id A04ED14C98 for ; Sun, 23 Jan 2000 11:48:22 -0800 (PST) (envelope-from pantzer@ludd.luth.se) Received: from speedy.ludd.luth.se (pantzer@speedy.ludd.luth.se [130.240.16.164]) by queeg.ludd.luth.se (8.9.3/8.9.3) with ESMTP id UAA01010; Sun, 23 Jan 2000 20:48:11 +0100 (CET) Message-Id: <200001231948.UAA01010@queeg.ludd.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: Mikhail Teterin Cc: David Schwartz , stable@FreeBSD.ORG Subject: Re: kern/13644 In-Reply-To: Message from Mikhail Teterin of "Sun, 23 Jan 2000 11:36:08 EST." <200001231636.LAA43285@rtfm.newton> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jan 2000 20:48:11 +0100 From: Mattias Pantzare Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. It is the upper limit. The kernel will put the program on the run queue when it noticeses that the time limit expires. The problem is simply that the kernel that has a lower resolution on it's scheduling than the clock that you are using, and that it takes time to do things on a noral CPU. From the man-page on solaris: whose members are 0, select() does not block. If the timeout argument is a null pointer, select() blocks until an event causes one of the masks to be returned with a valid (non- zero) value. If the time limit expires before any event occurs that would cause one of the masks to be set to a non-zero value, select() completes successfully and returns 0. Things will get even worse if your computer has a high CPU load or your process is on disk. By the way, solaris will do the same, but with a bit more precision, at least on sparc: Slept for 3452 instead of 2000 microseconds Slept for 9103 instead of 3000 microseconds Slept for 9955 instead of 4000 microseconds Slept for 9803 instead of 5000 microseconds Slept for 10136 instead of 6000 microseconds Slept for 9624 instead of 7000 microseconds Slept for 9964 instead of 8000 microseconds Slept for 9802 instead of 9000 microseconds Slept for 9880 instead of 10000 microseconds Slept for 20894 instead of 11000 microseconds Slept for 19450 instead of 12000 microseconds Slept for 19803 instead of 13000 microseconds Slept for 19731 instead of 14000 microseconds Slept for 19883 instead of 15000 microseconds Slept for 19887 instead of 16000 microseconds Slept for 19882 instead of 17000 microseconds And OSF1 on alpha: Slept for 2930 instead of 2000 microseconds Slept for 3906 instead of 3000 microseconds Slept for 4883 instead of 4000 microseconds Slept for 5859 instead of 5000 microseconds Slept for 6836 instead of 6000 microseconds Slept for 7813 instead of 7000 microseconds Slept for 8789 instead of 8000 microseconds Slept for 9766 instead of 9000 microseconds Slept for 10742 instead of 10000 microseconds Slept for 11719 instead of 11000 microseconds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message