Re: UDP recvmsg blocks after select(), 2.6 bug?

[Bodo Eggert]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/