From: snacktime <snacktime@...>
Date: 2005-10-04T17:51:43+09:00
Subject: Re: state of blocking/nonblocking I/O

------=_Part_6518_31333048.1128415900501
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/3/05, Robert Klemme <bob.news@gmx.net> wrote:
>
> Tanaka Akira <akr@m17n.org> wrote:
> > In article <52D38656-4CDB-46DA-A113-AC7415F568D6@reverberate.org>,
> > Joshua Haberman <joshua@reverberate.org> writes:
> >
> >> It seems that Ruby should keep track of whether a descriptor has
> >> O_NONBLOCK set (like in OpenFile.mode) and not do the select if so.
> >> On the other hand, that will break if O_NONBLOCK is set by a C
> >> extension, or by another process that has the same ofile open. Sigh.
> >
> > Yes. The shared fd is a problem hard to solve.
> >
> >> Now that I think of it, implementing IO#nonblock_read and
> >> IO#nonblock_write as extensions isn't feasible for the 1.8 branch,
> >> since it uses standard I/O which is incompatible with O_NONBLOCK.
> >> Sigh.
> >
> > They are not problem if IO#sync =3D true.
> >
> > Since streams created by Ruby (IO.pipe, TCPSocket.open, etc)
> > are IO#sync =3D true by default, the problem is not occur in
> > most cases.
> >
> >> I guess for now I'll have to use sysread/syswrite, along with a home-
> >> rolled buffering layer.
> >
> > You need your buffering layer if O_NONBLOCK is
> > used on ruby 1.8. However IO#sync =3D true is enough if
> > buffering is not required.
>
> I have one question on this matter which I still don't understand (I'm no=
t
> so deep into C stdlib IO variants so please bear with me): why would
> anybody
> want to use nonblocking IO (on the Ruby level, e.g. IO#read might not hav=
e
> read anything on return even if the stream is not closed) in the light of
> Ruby threads? I mean, with that one would have to build the multiplexing
> in
> Ruby which is already present in the interpreter with multiple Ruby
> threads?
> Are there situations that I'm not aware of where this is useful / needed?
> Thanks!
>
> Kind regards
>
> robert


I don't know exactly why this is, but an event framework using a single
event loop is far more efficient then a bunch of threads each doing their
own IO. Now this is with python and perl, ruby could be different although
that would surprise me. On a number of applications that I have converted
from threads to an event loop, cpu usage dropped like a rock.

Not to mention that the issue of synchronization pretty much goes away.

Chris

------=_Part_6518_31333048.1128415900501--