Messages in this thread |  | | Date | Wed, 25 Oct 2000 16:18:37 -0700 | From | Alfred Perlstein <> | Subject | Re: kqueue microbenchmark results |
| |
* David Schwartz <davids@webmaster.com> [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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |