> * 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.
Right. I can't imagine a way in which this could happen for TCP without a
bug. For other protocols, it's not so far fetched. For UDP, which is defined
as lossy, I could imagine an implementation that changed its mind about
accepting a packet due to memory demands.
> 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.
SuS2 says that 'read' behaves like 'recv' with no flags for a socket. SuS2
says that for a socket, "If no messages are available at the socket and
O_NONBLOCK is not set on the socket's file descriptor, recv() blocks until a
message arrives."
> Let's take a look at the FreeBSD manpage for poll:
>
> POLLIN Data other than high priority data may be read without
> blocking.
At the time you return from poll. This says nothing about any later time.
[snip]
> #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.
This brief comment is not meant to be thorough. In fact, it says nothing
about error conditions and implies that it's wrong to return POLLIN for an
error.
> 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?
When you code to a standard, your code must not fail under any conditions
permitted by the standard. Failing to set your file descriptors non-blocking
when you never want to block depends upon behavior not guaranteed.
Unfortunately, none of the standards provides sufficiently clear statements
about this behavior. In fact, I can't even find any standard that says it's
correct to signal POLLIN when there's an error.
DS
-
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