From owner-freebsd-bugs@FreeBSD.ORG Sun Oct 19 11:11:44 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3985316A4BF for ; Sun, 19 Oct 2003 11:11:44 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0210343FBF for ; Sun, 19 Oct 2003 11:11:43 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 20274 invoked from network); 19 Oct 2003 18:11:42 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail10.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Oct 2003 18:11:42 -0000 Received: from hydrogen.funkthat.com (crytyt@localhost.funkthat.com [127.0.0.1])h9JIBWCe059612; Sun, 19 Oct 2003 11:11:33 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id h9JIBWUh059611; Sun, 19 Oct 2003 11:11:32 -0700 (PDT) Date: Sun, 19 Oct 2003 11:11:32 -0700 From: John-Mark Gurney To: John Polstra Message-ID: <20031019181132.GD56592@funkthat.com> Mail-Followup-To: John-Mark Gurney , John Polstra , Boris Nikolaus , freebsd-bugs@freebsd.org References: <20031019130014.GA4033@fiesta.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Boris Nikolaus cc: freebsd-bugs@freebsd.org Subject: Re: kern/45291: kevent(2) ignores timeout if nevents == 0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 18:11:44 -0000 John Polstra wrote this message on Sun, Oct 19, 2003 at 10:38 -0700: > On 19-Oct-2003 Boris Nikolaus wrote: > > On Thu, Oct 16, 2003 at 10:09:58AM -0700, John-Mark Gurney wrote: > >> events to wait for. In fact, after reading select's manpage, this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> misfeature isn't documented, and select really should return EINVAL EBADF > >> if nfds is 0, and -1 is an invalid fd (which is the last fd that > >> select is suppose to check).. > > > > Select's manpage says, it checks all file descriptors from 0 to > > nfds - 1. The set of whole numbers which are >= 0 and <= -1 is empty, yes, but -1 is an invalid fd, so how can use that to put an upper bound on a set when that number isn't valid to describe the numbers for the set (the set of fds)? > > so select has to check no descriptors and waits for the timeout. This > > is exactly what select does, so this behaviour is implicitely > > documented. > > > > Changing select's behaviour as you suggest would break many software I never suggested that.. > > as this behavious is often used, both in main loops (which have to > > observe a set of file descriptors and timers and do not want to > > handle the case "only timers left" in a special way) and explicitely > > for sleeping (before microsleep/nanosleep have been invented, there > > was no function for sleeping with resolution below seconds, so the > > common way for sleeping in these cases was to call select with > > nfds == 0). > > Boris is right about this, John-Mark. If you think otherwise then > you really need to go read the code in a few real-world event loops. do you mean select loops? or event loops? I've written enough code on both. > They absolutely rely on this behavior of select. If anybody changed > it they'd have a whole lot of broken programs on their hands. You may > view it as a case of lazy programmers using the wrong system call for > sleeping, but in fact it is just the proper and most sensible behavior > for select to have at this boundary condition. I never suggested that we change/fix select. I'm simply saying that the manpage doesn't document the behavior everyone expects/sees... I was simply playing devil's advocate on this subject. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."