Messages in this thread | | | Date | Thu, 23 Aug 2001 11:30:34 +0100 | From | Mike Jagdis <> | Subject | Re: PROBLEM: select() says closed socket readable |
| |
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/
| |