From: Robert Klemme <bob.news@...>
Date: 2005-10-03T23:26:47+09:00
Subject: Re: state of blocking/nonblocking I/O

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 = true.
>
> Since streams created by Ruby (IO.pipe, TCPSocket.open, etc)
> are IO#sync = 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 = true is enough if
> buffering is not required.

I have one question on this matter which I still don't understand (I'm not 
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 have 
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