Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!husc6!bunny!dcr0 From: dcr0@GTE.COM (David Robbins) Newsgroups: comp.unix.aux Subject: Persistent Non-blocking I/O Message-ID: <7329@bunny.GTE.COM> Date: 25 Jul 89 12:39:58 GMT Organization: GTE Laboratories, Inc., Waltham, MA Lines: 34 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