Messages in this thread | | | Date | Sun, 19 Jun 2011 15:45:51 -0700 | Subject | Re: Does Linux select() violate POSIX? | From | Nemo Publius <> |
| |
On Sun, Jun 19, 2011 at 3:32 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > It's worth noting that the POSIX semantics are actually unimplementable > for some network protocols anyway particularly on send. TCP is a fine > example. A remote TCP isn't *supposed* to shrink its window but they can > do, and that that point the space select() saw for a send is closed down > again by the remote host.
Which makes me wonder what *BSD does for such a situation. Although not enough to check the source. :-)
> All sorts of similar issues appear all over the place. There are also > interesting API corner cases such as the behaviour of > > listen() > select > connection made > select returns > remote closes connection > accept > behaviour is not determinate
Hm, I thought this was what ECONNABORTED was for?
That is, accept() might return ECONNABORTED, or it might return a descriptor and then a later operation on that descriptor would fail with ECONNRESET... But either way, select() followed by accept() need not block.
> (and in general POSIX doens't address sockets well)
Well, no argument there.
> So for portable code always mix select and poll with non blocking I/O. It > doesn't matter what the specs say, the real world says drive defensively > 8)
No argument here, either. This was mostly for a barroom bet (well, StackOverflow... same thing), but also because I was curious. There are not a lot of ways in which Linux chooses to violate POSIX. Which might make a fun list to put together, come to think of it.
Thanks again, Alan. -- 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/
| |