From: Bill Kelly <billk@...>
Date: 2005-07-17T14:02:50+09:00
Subject: Re: Nonblocking Sockets

From: "Tanaka Akira" <akr@m17n.org>
> In article <01a001c58a52$13828780$6442a8c0@musicbox>,
>   "Bill Kelly" <billk@cts.com> writes:
>
> > ...Since select() said data was ready, AND since I'm
> > requesting a nonblocking operation... I have no idea
> > why #recvfrom sometimes hangs.  
> 
> Hmm.  Linux, UDP, readable by select, not readable by recvfrom.
> 
> It may be caused by wrong UDP checksum.
> 
> Linux-Kernel Archive: UDP recvmsg blocks after select(), 2.6 bug?
> http://www.ussg.iu.edu/hypermail/linux/kernel/0410.0/1372.html
> 
> Debian Bug report logs - #275585 - /usr/sbin/inetd: UDP builtins can be used to hang inetd
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275585&archive=yes

Thank you!  A most interesting read.

> > It used to totally hang
> > my program (on linux), indefinitely, about once a day,
> > until I added the timeout().
> 
> It seems that Ruby process doesn't hang because timeout works.
> timeout is implemented by Ruby thread.
> 
> So your problem is IPSocket#recvfrom retry when EAGAIN.
> 
> You may need lower level method which makes EAGAIN user visible.

Starting with
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.0/1837.html
there were some number of messages in the thread saying
they can't return EAGAIN in this situation because 
POSIX forbids it.  (But that's in the nonblocking case.)

Since I'm requesting O_NONBLOCK prior to recvfrom(), 
shouldn't it ............ ahh "your problem is
IPSocket#recvfrom retry when EAGAIN."  Hmm.....

Interesting, doesn't that imply IPSocket#recvfrom is
essentially broken for NONBLOCK semantics?  What I mean
is, if the socket is in nonblocking mode, and recvfrom()
gets an EAGAIN, shouldn't it just return nil to the
caller?  (Or whatever the TCP methods do in a NONBLOCK
situation?)  Why should it ever "block" in a NONBLOCK
situation?


Thanks,

Regards,

Bill