Tanaka Akira wrote:
> In article <42F996FE.3000702 / path.berkeley.edu>,
>   Joel VanderWerf <vjoel / path.berkeley.edu> writes:
> 
> 
>>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?
> 
> 
> Ruby threads is not native threads.
> In [ruby-talk:148436], the entire process is not blocked because
> O_NONBLOCK is used.
> 
> 
>>I tried to hang ruby with
>>
>>  hping2 --udp -p 9999 -b
>>
>>but the socket did not block.
> 
> 
> I can see the entire process blocking with following script.
> 
> server% uname -a
> Linux nute 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux
> server% ./ruby -rsocket -e '
> Thread.new { 1000.times {|i| p i; sleep 1 } }
> u = UDPSocket.new; u.bind("0.0.0.0", 2000)
> p u.recv(100)'
> 
> client% hping2 --udp --count 1 --badcksum --destport 2000 server

Hm, it doesn't block for me, but it does exit the ruby process:

$ ruby -rsocket -e '
Thread.new { 1000.times {|i| p i; sleep 1 } }
u = UDPSocket.new; u.bind("0.0.0.0", 2000)
p u.recv(100)'
0
1
2
""
$ uname -a
Linux tumbleweed 2.6.10-5-686 #1 Fri Jun 24 17:33:34 UTC 2005 i686 GNU/Linux
$ ruby -v
ruby 1.8.2 (2004-12-25) [i686-linux]

This is with the same hping2 line:
# /usr/sbin/hping2 --udp --count 1 --badcksum --destport 2000 localhost
HPING localhost (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes

--- localhost hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

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