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.
Also they cannot be combined with buffering methods.

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.

> Ooh, that's bad.  What's the explanation for that?

R. Stevens says

  using standard I/O with nonblocking descriptors,
  a recipe for disaster

UNIX Network Programming Vol1, p.399

For more information, read the source of fflush in stdio.
Version 7, 4.4BSD and glibc has the problem as far as I
know.  I feel it's portable behavior.

> Yes, but IO.select can't tell me how *much* data I can read or  
> write.  IO#read and IO#write can still block if I try to read or  
> write too much data, which is what I want to avoid.

IO#readpartial is available since ruby 1.8.3.
It doesn't block if some data available.

For writing, I think IO#syswrite is required.
-- 
Tanaka Akira