select() on UDP does not guarantee recvfrom() won't block

[Alan DeKok]

Ryan Melendez wrote:
> I've always thought that if I select on a blocking UDP socket that I can
> assume that a read subsequent read will not block.  Apparently that is
> not the case.  select on linux can in fact lie, it is only a hint.  They
> suggest that O_NONBLOCK should be used with select.

  Idiots.

  Standards exist for a reason.  Sometimes they're wrong (witness what
will be RFC 5080), but ignoring them is often a bad idea.

> I'm linking the _long_ thread if anyone is interested.

  Many Linux people don't understand networking, and many don't
understand the benefits of application stability.  (See the comments on
O(1) scheduler: "it's only 15 steps for 32k processes, and 16 steps for
64k processes.  Since 15 and 16 are both small numbers, it's O(1) in the
number of processes, right?)

  The only sane response is: WTF?  These people are allowed to code?

> This is not a new development, but it is new to me.  Has this been
> discussed on the list?  The reason I am asking is that I've recently
> come across a problem where my 1.1 freeradius deamon is blocking on
> recvfrom on port 1814.

  It appears to be new to 2.4, and more likely with 2.6.  It's wrong.
Their arguments are *nonsense*.

> Do you guys consider it fundamentally wrong to select on blocking UDP
> sockets?

  No,  If Linux blocks on recv() after select() returns "data available"
for a UDP socket, then Linux is broken.  It doesn't follow Posix, as
people in the thread point out.  Many of the comments in the thread
*for* this behavior talk about broken pthread applications.  This says
to me that they *know* their arguments are nonsense, so they have to
invent even more nonsensical reasons why it's the application's fault.

  It looks like I'll have to update the code to set O_NONBLOCK.  This
requires a number of minor changes in some areas.

  But Linux is broken.  I've been doing networking for a long time, on
AIX, HP/UX, SunOS, Solaris, Windows (98, NT, XP), Mac, *BSD, Linux, and
I know a number of the people who've developed the network
specifications and implementations.

  Linux is broken.  It does not follow Posix, and it does not follow
decades of network practice.  If the Linux children do not understand
this, they need to be educated.  Bluntly.

  Alan DeKok.