Date: Wed, 25 Oct 2000 15:34:08 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Jonathan Lemon" <jlemon@flugsvamp.com> Cc: <chat@freebsd.org>, <linux-kernel@vger.kernel.org> Subject: RE: kqueue microbenchmark results Message-ID: <NCBBLIEPOCNJOAEKBEAKCEOPLHAA.davids@webmaster.com> In-Reply-To: <20001025172702.B89038@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote: > > > > > Now, next time around the loop, we get a notification for an event > > > when there is no data to read. The application now must be prepared > > > to handle this case (meaning no blocking read() calls can be used). > > > -- > > > Jonathan > > > > If the programmer never wants to block in a read call, he > > should never do a > > blocking read anyway. There's no standard that requires > > readability at time > > X to imply readability at time X+1. > > Quite true on the surface. But taking that statement at face value > implies that it is okay for poll() to return POLLIN on a descriptor > even if there is no data to be read. I don't think this is the intention. Never mind what it implies. Just stick to what it says. :) In my opinion, it's perfectly reasonable for an implementation to show POLLIN on a call to poll() and then later block in read(). As far as I know no implementation does this, but no standard prevents an implementation from, for example, swapping out received TCP to disk if it's not retrieved and blocking later when you ask for the data until it can get the data back. I would even argue that it's possible for an implementation to decide that a connection had errored (for example, due to a timeout) and signalling POLLIN. Then before you call 'read', it gets a packet and decides that the connection is actually fine and so blocks in 'read'. This wouldn't seem possible in TCP, but it's possible to imagine protocols where it's sensible to do. And again, as far as I know, no standard prohibits it. 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. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBLIEPOCNJOAEKBEAKCEOPLHAA.davids>