From: Anatoly Karp <ankarp1@...>
Date: 2006-05-21T14:52:29+09:00
Subject: Re: sysread changes behavior in the presence of threads?

On 5/21/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> Tanaka-sensei: from your description it appears that the problem is caused
> by an interaction between the Ruby thread-scheduler and the I/O functions,
> which can't be resolved without fundamentally changing how the scheduler
> works. That's fair enough.
>

I am not sure Tanaka's explanation is quite satisfactory. If you change
your original example thusly:

require 'socket'
require 'fcntl'
Thread.new { puts "hi" }
sd = TCPsocket.new( "www.cisco.com", 80)
m = sd.fcntl( Fcntl::F_GETFL, 0)
sd.fcntl( Fcntl::F_SETFL, Fcntl::O_NONBLOCK | m)
sd.sysread(4096)

it will produce Errno::EAGAIN as expected.

Thus, one is led to suspect that in the former case the thread somehow
does not get properly cleaned up upon completion.

In any case, I agree with you that not being able to count on non-blocking
behavior, just because there could be some stray Threads around, is
pretty nasty.

-A