Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: UDP recvmsg blocks after select(), 2.6 bug? | Date | Sat, 09 Oct 2004 15:24:06 +0200 |
| |
David S. Miller wrote:
> People, get the heck over this. The kernel has behaved this way > for more than 3 years both in 2.4.x and 2.6.x. The code in question > even exists in the 2.2.x sources as well. > > Therefore, it would be totally pointless to change the behavior > now since anyone writing an application wishing it to work on > all existing Linux kernels needs to handle this case anyways.
If you want people to write workaround for functions that intentional break applications depending on dysfunctional behaviour, you should document it. You didn't, and therefore most applications will be broken:
google survey: Results 1 - 10 of about 13,100 for udp select recv. (0.18 seconds) Results 1 - 10 of about 636 for udp select recv o_nonblock. (0.16 seconds)
Results 1 - 10 of about 4,350 for select recv SOCK_DGRAM. (0.40 seconds) Results 1 - 10 of about 685 for select recv SOCK_DGRAM o_nonblock. (0.39 seconds)
I think nobody complaining results from nobody sending bad UDP packets, and nobody sending bad UDP packets resulted from nobody complaining.
BTW: If you're breaking select() for blocking sockets, you can as well return -EBROKEN. It's as close to the specification as waiting after guaranteeing not to wait, but it will not result in hidden flaws. -- Fun things to slip into your budget Request for 'supermodel access' to the UNIX server. Just don't tell the PHB why your home directory is named 'jpgs.' - 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/
| |