* 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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:17 EST