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

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

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.

By this point, I've accumulated a small library of functions in C that
perform various operations without blocking, and are unaffected by the
presence of threads. Perhaps I'll release them as an extension library so
people can use them now, while recognizing that they will be eventually
obsoleted when a decision is made about the names to be used in the standar=
d
distro. (Another thing I'd like to do is write a unified Mutex/Condition
Variable implementation that can actually be used to synchronize Ruby
threads with native threads.)

On 5/20/06, Tanaka Akira <akr@m17n.org> wrote:
>
> In article <3a94cf510605201832g5a8d23cue1f0e2e69661d5f1@mail.gmail.com>,
>   "Francis Cianfrocca" <garbagecat10@gmail.com> writes:
>
> > 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 se=
e
> the
> > 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.
>
> A workaround is Thread.exclusive { sd.sysread(4096) }.
>
> However I think a nonblocking read method is right way to
> fix this issue.  The problem is the method name, though.
>
> There are several problems to fix sysread to cause EAGAIN in
> I/O multiplex mode.  Since a nonblocking I/O doesn't block,
> it is possible to avoid I/O multiplex to avoid entire
> process blocking.  So if Ruby disables I/O multiplex for
> nonblocking I/O, sysread will cause EAGAIN.  But,
> unfortunately, Ruby cannot know nonblocking state of a fd in
> some case.
>
> 1. Windows has no F_GETFL equivalent
>   There is no way to know the state on Windows.
>
> 2. race condition
>   Even on an environment which has F_GETFL, the state may be
>   changed between F_GETFL and read(2) by another process.
> --
> Tanaka Akira
>
>

------=_Part_179988_4415110.1148187675046--