RE: PROBLEM: select() says closed socket readable

["David Schwartz" <davids@webmaster.com>]

> David S. Miller wrote:
> >    From: Jay Rogers <jay@rgrs.com>
> >    Date: Mon, 20 Aug 2001 10:34:09 -0400
> >
> >    > Right. It does not block on read, hence it is readable.
> >
> >    No, a socket that's never been connected isn't readable, hence
> >    select() shouldn't be returning a value of 1 on it.
> >
> > You may read without blocking, select() returns 1.

> By this logic a socket that is set non-blocking should always be
> treated as readable. I think we can all agree that argument is
> flawed :-).

	No, because 'select' is defined to work the same on both blocking and
non-blocking sockets. Roughly, select should hit on read if a non-blocking
read wouldn't return 'would block'.

> The prevailing view from other systems appears to be that reading
> from an unconnected (or unconnectING) socket is meaningless so
> the socket is not readable.

	So is reading from a closed or errored socket. There is nothing to wait
for, so why should the system call wait?

> Presumably there is a damn good reason, or a standards reference,
> why that is the wrong behaviour and should be changed?

	If you think about the cases where someone might actually do this, odds are
you want the application's error handling code to launch. That won't happen
if you never break out of select. However, if you do break out of select, do
a read, and get an error, the problem will then be handled, rather than
ignored.

	DS