Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!ulysses!ggs From: ggs@ulysses.homer.nj.att.com (Griff Smith) Newsgroups: comp.unix.questions Subject: Re: Asynchronous output Message-ID: <1538@ulysses.homer.nj.att.com> Date: Thu, 18-Dec-86 11:30:07 EST Article-I.D.: ulysses.1538 Posted: Thu Dec 18 11:30:07 1986 Date-Received: Fri, 19-Dec-86 00:01:44 EST References: <1858@batcomputer.tn.cornell.edu> Organization: AT&T Bell Laboratories, Murray Hill Lines: 41 In article <1858@batcomputer.tn.cornell.edu>, garry@batcomputer.UUCP writes: > I have an application which entails computing and churning out vast > quantities of data and, for speed, I'd like to have the I/O happening > in parallel with the computing. After reading the BSD and SysV manuals, > I'm puzzled: does the system give us *any way* to do asynchronous output? > > I've thought of writing a (presumably buffered) pipe to "cat" and thence to > my device. Is there anything else? > > garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) It depends on who else is using the computer, where you are putting your data, etc. If you are writing to a disk file, don't worry; the disk system is buffered internally. If you are writing to a mag tape and you are the only one on the system, you might want to fork a tape writing process. If you are using System V, you could even use shared memory to pass data to the process without writing or copying it. If shared memory isn't available, try a pipe. Remember, though, that pipes aren't free. The time it takes for one process to write the pipe and another to read it may be larger than the time spend waiting for the tape to spin. If the system is heavily loaded, complicated multi-process buffering schemes may slow you down; the system will just run something simpler instead. Your best strategy is usually to minimize your own cpu requirements so you make the best use of the fraction of the cpu allocated to you. Of course, if you have the machine to yourself the only thing that matters is elapsed time, not cpu time. In that case, you might consider running something else useful to soak up the idle time. You still won't get the primary job done any faster, but the total productivity of the system should improve. After an experience I had about 7 years ago I am not very enthusiastic about asynchronous I/O in time-sharing systems. We were using TOPS-10, which had a buffering scheme for asynchronous I/O. After having many problems in the kernel caused by cache maintenance errors during asynchronous I/O, we defeated the asynchronous feature. The system itself was still highly asynchronous, but not within processes. Users didn't know the difference but the system did: improved system stability, better system throughput, faster disk performance, less disk fragmentation.