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

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

I'd be inclined to categorize it as a bug. It violates the expectation that
I/O is orthogonal to threads. I looked at the code in io.c and I can see th=
e
reason for it, but I'm writing a library and I don't have the luxury of
making assumptions about whether there are other threads.

On 5/20/06, Bill Kelly <billk@cts.com> wrote:
>
> From: "Francis Cianfrocca" <garbagecat10@gmail.com>
> > Ahh, thanks for pointing it out, although it ain't the answer I was
> hoping
> > for. Interesting that your concern (not having to think about EAGAIN) i=
s
> > opposite from mine- I'm *wanting* to get EAGAIN so I can do something
> else
> > while waiting for the I/O.
>
> Yeah.  I didn't have a specific need to check for EAGAIN at the
> time, but my main point was trying to express my confusion that
> there would be this one semi-obscure case (single thread only)
> that acted differently from the rest.  I say obscure because I
> don't think I'd ever write code in ruby to expect that no other
> threads were present in the system.  How would I know that
> some other library I've required hasn't spawned some worker
> thread for its own internal use?  So having ruby act
> inconsistently in the particular case of there being only one
> thread alive seems peculiar to me.  So my point was I was
> confused by that behavior since it seems like something I could
> never be able to reliably expect to depend on.  :)
>
>
> Regards,
>
> Bill
>
>
>
>

------=_Part_179116_22958407.1148175121240--