Path: utzoo!attcan!uunet!ginosko!ctrsol!cica!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!nc386!allbery
From: allbery@nc386.UUCP (Brandon S. Allbery)
Newsgroups: comp.unix.aux
Subject: Re: Persistent Non-blocking I/O
Message-ID: <1989Jul30.184201.1517@nc386.uucp>
Date: 30 Jul 89 18:42:01 GMT
References: <7329@bunny.GTE.COM>
Sender: allbery@nc386.uucp (Brandon S. Allbery)
Reply-To: allbery@nc386.UUCP (Brandon S. Allbery)
Organization: North Coast Computer Resources, Cleveland, OH
Lines: 40
In-reply-to: dcr0@GTE.COM (David Robbins)

In article <7329@bunny.GTE.COM>, dcr0@GTE (David Robbins) writes:
+---------------
| 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
+---------------

Under System V-style Unixes, non-blocking I/O is an attribute of the file
table entry; under BSD, it (seems to be) part of the local file descriptor.
(It is possible to put flags on an fd under System V, but I'd guess that
various parts of the kernel would have difficulty finding the right fd without
a total rewrite of the file-handling subsystem.  The only fd-local flag in
System V is close-on-exec.)

I would agree that the BSD implementation is more "polite"; on the other hand,
it can be argued that the System V implementation makes for (a) a cleaner
kernel and (b) consistency, since O_NDELAY then acts like all other file
attributes (except close-on-exec, which is handled as a separate kind of
attribute anyway).

I always save and restore that kind of context when I muck with it in my
programs, on general principles.

I should comment, though:  sounds like A/UX's init may be broken.  The
O_NDELAY flag should be cleared when the file descriptor is closed (when the
login shell exits), and init's console message channel should *not* be the
same file structure as the one opened by the console getty, so after an
NDELAY-caused logout the console should be fine again.  Perhaps someone at
Apple was trying to "optimize" init by special-casing the console?  (ugly!)

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
   * This message brought to you courtesy the "Watcher" for the 4th NCoast *