David Schwartz wrote:
[assumptions deleted]
> Of course, this isn't so much of a benefit that it's worth violating a
> standard like POSIX. But it could be considered enough of a benefit that
> it's worth not being compatable outside the bounds of such a standard.
Let's think about the _facts_ for a second. In the case where select on
an unconnected socket succeeds (because a read would not block) a
process that does this would not sleep in select. If the select does
not succeed (because the socket is not ready to read) then the process
sleeps.
In the first case the process either eats CPU time or gets an error
when it reads the socket. But does it handle the error? Does it even
do the read - why should it read the unconnected socket at all?
In the second case the process either hangs or behaves as expected.
It may even recover gracefully if the socket is subsequently connected.
Case 1 leads to spin-or-die and case 2 leads to block-and-work.
Case 1 assumes that selecting for read on an unconnected socket is
an error. Case 2 doesn't - an unconnected socket is simply never
"ready to read".
Other systems use the "ready to read" interpretation. The Single
UNIX Spec states "ready to read". The Linux man page uses "ready
to read" but adds a parenthetical "read will not block" to allow
EOF. Linux itself implements "will not block".
I can find nothing that even suggests that selecting on an unconnected
socket is an error.
Linux is wrong. Patch follows.
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:55 EST