From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-21T15:13:33+09:00
Subject: Re: sysread changes behavior in the presence of threads?

------=_Part_180428_21761811.1148192010165
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In your example, the thread ends almost immediately, especially since puts
will probably complete long before a connect to a remote web server. So by
the time the sysread executes, there is only one thread. Tanaka's
explanation still holds.

I think the answer is to define a new set of functions that can be depended
on not to block. (And on Windows, they will probably also need to set the
descriptor nonblocking.) From prior communications with Matz, he's not
against this, but hasn't settled yet on what these new methods should be
named.

On 5/21/06, Anatoly Karp <ankarp1@gmail.com> wrote:
>
> 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 schedule=
r
> > 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 =3D TCPsocket.new( "www.cisco.com", 80)
> m =3D 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-blockin=
g
> behavior, just because there could be some stray Threads around, is
> pretty nasty.
>
> -A
>
>

------=_Part_180428_21761811.1148192010165--