From: Joshua Haberman <joshua@...>
Date: 2005-10-03T11:38:02+09:00
Subject: Re: state of blocking/nonblocking I/O

On Oct 2, 2005, at 7:07 PM, Tanaka Akira wrote:

> In article <3AF4F3D8-8D17-4E06-9F52-B8B5A4230AD5@reverberate.org>,
>   Joshua Haberman <joshua@reverberate.org> writes:
>
>
>> Hrm, so I guess that if I want to do real nonblocking I/O in Ruby, I
>> have to write IO#nonblock_read and IO#nonblock_write, that do not
>> have this retry behavior?
>>
>
> IO#sysread and IO#syswrite is possible candidates.
> However they may block when multithreaded because select.

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.

> Nonblocking methods such as IO#nonblock_read and
> IO#nonblock_write is good idea.  If matz accept it, I'll
> implement them definitely.  However I'm not sure that matz
> think the method names are good enough.

Well I don't know if will help convince matz, but djb advocates that  
naming scheme as well, for C:

http://cr.yp.to/unix/nonblock.html

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.

I guess for now I'll have to use sysread/syswrite, along with a home- 
rolled buffering layer.

>> Ooh, that's bad.  What's the explanation for that?
>>
>
> R. Stevens says
>
>   using standard I/O with nonblocking descriptors,
>   a recipe for disaster

I guess that says it all.  :)

Josh