Tanaka Akira wrote:
> In article <42F97309.3040901 / path.berkeley.edu>,
>   Joel VanderWerf <vjoel / path.berkeley.edu> writes:
> 
> 
>>>* read from socket: works well by default. (O_NONBLOCK is not required.)
>>>  (UDP packet with wrong checksum on Linux 2.6 is an exception.)
>>
>>Can you say a bit more about what happens differently on Linux 2.6 when
>>a UDP packet has a bad checksum? Is it a ruby behavior or a linux behavior?
>>
>>(I'm working with wireless UDP on linux 2.6, having migrated from QNX,
>>so it sounds important to me...)
> 
> 
> Linux 2.6's select notify readability by a UDP packet with a bad checksum.
> But read discards it and waits next packet with a correct checksum if
> O_NONBLOCK is clear.  If the next packet is not available, the read
> hangs.  Since O_NONBLOCK avoids the hang, it is possible to care the
> problem in application level.
> 
> 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
> 
> select(2):
>        Under Linux, select may report a socket file descriptor as  "ready  for
>        reading",  while  nevertheless a subsequent read blocks. This could for
>        example happen when data has arrived but  upon  examination  has  wrong
>        checksum  and  is discarded. There may be other circumstances.  Thus it
>        may be safer to use O_NONBLOCK on sockets that should not block.
> 
> [ruby-talk:148436] Nonblocking Sockets

That post (148436) suggests that the native thread running the
interpreter is not blocked, and the only danger of blocking is in the
*ruby* thread reading the socket. Is that right? A bad UDP packet won't
stop other ruby threads?

I tried to hang ruby with

  hping2 --udp -p 9999 -b

but the socket did not block.

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407