geoff@proper.UUCP (Geoff Kuenning) (02/07/84)
A request was made on the net for information on how to do a non-blocking read from a terminal. Under 4BSD and UniSoft ports, the FIONREAD 'ioctl' can be used to check for characters, albeit at a high cost in CPU time. Other solutions have been posted to the net. A related question is how to do asynchronous disk I/O for purposes of double buffering. System V provides an open/fcntl option for non-blocking (read asynchronous) I/O, but there is a *VERY* nasty catch: there is no way to find out when the I/O is finished! This makes the non-blocking feature pretty useless. Indeed, when I examined the double-buffering code in "volcopy" to find out how they did it, I discovered that they fork a copy of themselves and then write "r" and "w" characters across pipes to synchronize the two copies. Each copy is responsible for working with one of the two buffers, and writes a single character to the other copy when the buffer is complete. YUCCCCCCH! KLUDGE KLUDGE KLUDGE! How about it, Bell Labs? If you are going to provide non-blocking I/O, I really think you should give us a way to find out when the I/O is complete. I fully realize the difficulty of integrating such a feature into the Unix design; but I still think you should do it the right way.
54394gt@hocda.UUCP (G.TOMASEVICH) (02/09/84)
OK, Geoff! Let's hear it for non-blocking disk (and tape) reads for which you can find out when they are done. I read that 'volcopy' kludge, too.
guy@rlgvax.UUCP (Guy Harris) (02/17/84)
> UNIX was designed to appear synchronous at the user I/O level and > it does a nice job of this. If you really want asynchronous file I/O > why not change to VMS. Because synchronous I/O is not appropriate for all applications, and it's a pain to have to swallow the rest of VMS just to get asynchronous I/O. For instance, Michael Stonebraker's paper on OS support for databases mentions several problems with UNIX I/O (the fact that you only have sequential read-ahead, when often the application knows what block it will want soon) which could be fixed with asynchronous I/O. UNIX wasn't originally designed to do a lot of things it currently does fairly well (for instance, it originally wasn't designed to support virtual memory); if it hadn't been able to be extended to support new applications, it may have remained a Bell Labs and maybe university curiosity. As such, it would have been an interesting research project but wouldn't have become significant in the larger world of computing. (Admittedly, there are some die-hard hackers out there who would have considered that a better outcome, but to each their own...) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
rpw3@fortune.UUCP (02/18/84)
#R:sri-arpa:-1667000:fortune:11600068:000:458 fortune!rpw3 Feb 17 20:51:00 1984 +-------------------- | From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> | | UNIX was designed to appear synchronous at the user I/O level and | it does a nice job of this. If you really want asynchronous file I/O | why not change to VMS. +-------------------- You might not be on a VAX. Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065