Persistent Non-blocking I/O

[David Robbins]

I've run into an "interesting" situation with non-blocking I/O in A/UX.  I have
a program that for various reasons needs to do non-blocking input.  It sets the
input file into non-blocking mode with the following call:

   fcntl(fd, F_SETFL, FNDELAY);

And this works perfectly well, on all the systems where my program runs
(A/UX, Ultrix, and SunOS).  The input doesn't block, just as advertised.

The surprise comes later.  I would expect that non-blocking mode is in
effect only within the process that executed the aforementioned call.  This
expectation holds true in Ultrix and in SunOS.  The surprise is that in A/UX
the expectation does not hold true.  In particular, when the program's input
is the console or a pseudo-tty, the program having been invoked from a shell,
the console or pty remains in non-blocking mode even after the program
terminates.  The result, of course, is that the shell on its next read
sees no input available and thinks that it is time to terminate.  And when
it is the console for which this has occurred, I am instantly logged out and
getty gets continuous EOFs reading the console and eventually gives up.
A system reboot seems the only cure.

The behavior clearly suggests that non-blocking mode has been associated with
the device itself rather than with the process using the device.  This
behavior is not observed in other implementations of UNIX, and the
documentation does not appear to suggest that this behavior is intended
in A/UX.

Has anyone else noticed this?  Is this a bug in A/UX?  Or is this in fact
the way the world is supposed to be, and I'm just a bit slow?
-- 

Dave Robbins                    GTE Laboratories Incorporated
drobbins at gte.com                40 Sylvan Rd.
...!harvard!bunny!drobbins      Waltham, MA 02254