Subject: Re: GET THIS BOOK :)
To: Bill & <>
From: Greg Hudson <ghudson@MIT.EDU>
List: current-users
Date: 07/31/1994 16:51:23
> (There *are* structural problems with UNIX, though, especially in
> the area of the terminal driver, but that's really off-topic for
> this list.  For example, see what happens to your shell when you run
> a program which sets non-blocking mode on your TTY and then
> exits...)

Actually, I do think that's related to this list.  The problem here is
that fcntl()'s FL_NONBLOCK flag applies to the open file description
pointed to by a file descriptor.  Multiple processes can have file
descriptors refeerring to the same open file description (e.g. the
stdin of a program usually has the same OFD as the stdin of its
shell), and when one process sets the file descriptor non-blocking,
the other process suddenly starts getting EAGAINs from its read() and
write() calls.

The only explanation for this, as far as I can tell, is that no one
was paying attention when they standardized this in POSIX.  A simple
solution is to add a second flag FD_NONBLOCK which applies only to the
file descriptor.  read() and other blocking system calls will return
EAGAIN if either the file descriptor or its corresponding open file
description are set non-blocking.  This way, programs can set their
file descriptors non-blocking without fear of sabotaging other
processing using the same OFDs.

The issue is relevant to this list because if enough operating systems
add FD_NONBLOCK, POSIX may take notice of it, standardize it, and
possibly even deprecate FL_NONBLOCK.  Even if FD_NONBLOCK is never
standardized, certain packages (for instance, Proven's threads
library) can operate much more robustly with support for
per-file-descriptor non-blocking flags.