dcr0@GTE.COM (David Robbins) (07/25/89)
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@gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254
allbery@nc386.UUCP (Brandon S. Allbery) (07/31/89)
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 *