Messages in this thread | | | Date | Thu, 7 Oct 2004 01:11:14 +0200 | From | Willy Tarreau <> | Subject | Re: UDP recvmsg blocks after select(), 2.6 bug? |
| |
Hi,
On Wed, Oct 06, 2004 at 09:25:28PM +0100, Alan Cox wrote:
> The current setup has so far been found to break one app, after what > three years. It can almost double performance. In this case it is very > much POSIX_ME_HARDER, and perhaps longer term suggests the posix/sus > people should revisit their API design.
Couldn't we simply make recvfrom() return 0 (no data) or -1 (whatever error) in a case where select() had a reason to believe that there were data, but that the copy function discovered that it was corrupted data ?
This should not impact performance and would let recvfrom() behave in a smarter way. After all, I don't see a problem receiving 0 bytes.
Anyway, I'm all for non-blocking I/O, but I can understand the stupidity of the situation.
Just a few thoughts, of course. Willy
- 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/
| |