Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: UDP recvmsg blocks after select(), 2.6 bug? | Date | Thu, 7 Oct 2004 17:19:20 -0700 |
| |
> > POSIX does not require the kernel to predict the future. The > > only guarantee > > against having a socket operation block is found in > > non-blocking sockets.
> It is one thing to implement select()/recvmsg() in a non POSIX compliant > way; it is another thing to make false claims about that standard. POSIX > _does_ guarantee that a call to recvmsg() does not block after a call > to select().
I do not believe this.
> > Suppose, for example, that instead of using 'read' you used > > 'recvmsg', and > > we add an option to 'recvmsg' to allow you to read datagrams with bad > > checksums. What should 'select' do if a datagram is received with a bad > > checksum? It has no idea what flavor of 'recvmsg' you're going > > to call, so > > it can't know if your operation is going to block or not.
> This is all described in detail in the standard.
Where, specifically, does the standard guarantee that a subsequent call to 'recvmsg' will not block?
> > No, you are incorrect. Consider, again, a 'recvmsg' flag to allow you to > > receive messages even if they have bad checksums versus one that blocks > > until a message with a valid checksum is received. The 'select' function > > just isn't smart enough. > > > > Consider a 'select' for write on a TCP socket. How does > > 'select' know how > > many bytes you're going to write? Again, a 'select' hit just indicates > > something relevant has happened, it *cannot* guarantee that a future > > operation won't block both because 'select' has no idea what > > operation is > > going to take place in the future and because things can change > > between now > > and then.
> You really should read the standard on this..
I have. We obviously disagree on what it says. Since you're the one claiming a guarantee that I claim does not exist, perhaps you could cite where you think this guarantee appears.
DS
- 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/
| |