From owner-freebsd-chat Wed Oct 25 16:18:45 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3710F37B4C5 for ; Wed, 25 Oct 2000 16:18:39 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9PNIbo00948; Wed, 25 Oct 2000 16:18:37 -0700 (PDT) Date: Wed, 25 Oct 2000 16:18:37 -0700 From: Alfred Perlstein To: David Schwartz Cc: Jonathan Lemon , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025161837.D28123@fw.wintelcom.net> References: <20001025172702.B89038@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from davids@webmaster.com on Wed, Oct 25, 2000 at 03:34:08PM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Schwartz [001025 15:35] wrote: > > If a programmer does not ever wish to block under any circumstances, it's > his obligation to communicate this desire to the implementation. Otherwise, > the implementation can block if it doesn't have data or an error available > at the instant 'read' is called, regardless of what it may have known or > done in the past. It's also just generally good programming practice. There > was a time when many operating systems had bugs that caused 'select loop' > type applications to hang if they didn't set all their descriptors > non-blocking. Yes, and as you mentioned, it was _bugs_ in the operating system that did this. I don't think it's wise to continue speculating on this issue unless you can point to a specific document that says that it's OK for this type of behavior to happen. Let's take a look at the FreeBSD manpage for poll: POLLIN Data other than high priority data may be read without blocking. ok no one bothers to do *BSD compat anymore (*grumble*), so, Solaris: POLLIN Data other than high priority data may be read without blocking. For STREAMS, this flag is set in revents even if the message is of zero length. I see a trend here, let's try Linux: #define POLLIN 0x0001 /* There is data to read */ This seems to imply that it is one hell of a bug to block, returning an error would be acceptable, but surely not blocking. I know manpages are a poor source for references but you're the one putting up a big fight for blocking behavior from poll, perhaps you can point out a standard that contradicts the manpages? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message