Messages in this thread | | | Date | Wed, 22 Aug 2001 10:26:11 +0100 | From | Mike Jagdis <> | Subject | Re: PROBLEM: select() says closed socket readable |
| |
David Schwartz wrote:
> 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'.
Which may be the root of the problem. Linux seems to consider that select indicates "would not block", whereas Solaris et. al. use "ready to read". (The difference seems to exist in man pages too) Clearly an unconnected socket "would not block" but is not "ready to read".
> 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.
No. If there is a correct behaviour defined in a standard we should do that. Otherwise we should do what other systems do _unless_ there is a clear benefit to doing something else. In this case doing something else appears to create porting problems and confusion over what select(2) means without any clear benefit.
So, we're back to the beginning: justify with reference or reason :-).
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/
| |