From: Paul Brannan <pbrannan@...>
Date: 2004-02-28T00:30:01+09:00
Subject: Re: ruby-dev summary 22877-23014

On Fri, Feb 27, 2004 at 01:59:38PM +0900, Tanaka Akira wrote:
> My point is that sysread (or sysread like method which care stdio
> buffer) is better than nonblocking read.
> 
> I think they are useful in similar cases.

What about non-blocking writes?

(I rarely put an fd in non-blocking mode to read, because I can easily
enough keep my app from blocking on a read by simply not reading when
there isn't data to read; if I put an fd in non-blocking mode, it is
almost always for writing).

> > If a programmer creates a child process and uses a parent processes's
> > file descriptor in the child, he'd better know what he is doing, whether
> > the non-blocking flag is set or not.
> 
> I think usual program expects non-blocking flag is clear.  For
> example, following problem is caused because cvs (stdio) doesn't
> expect stderr is nonbloking.
> 
> http://groups.google.com/groups?th=e4df2fdc1f4f4950
> http://sources.redhat.com/ml/bug-glibc/2002-08/threads.html#00041
> http://sources.redhat.com/ml/bug-glibc/2002-08/threads.html#00186

So it's not a good idea to use non-blocking IO with stdio.  There are
plenty of other IO objects that I use non-blocking IO with, especially
sockets.

> Since there are much code which expect file descriptor which
> non-blocking flag is clear, nonblocking-mode should be avoided if
> possible.  So Ruby should not recommend nonblocking IO by providing
> easy-to-use method to make IO nonblocking.

I have code that expects that the non-blocking flag is not clear.  The
rule should be to not mix non-blocking fds with code that expects a
blocking fd and vice versa.

> However someone who know what he is doing can make IO nonbloking using
> IO#fcntl anyway.

This is true.  And I'm not sure that:

  socket.fcntl(Fcntl::F_SETFL, Fcntl::O_NONBLOCK)

is any less clear to read then

  socket.nonblock = true

except that Ruby might do something other than an fcntl under the hood
in the latter case, depending on the platform.

Paul