Xref: utzoo comp.lang.misc:5420 comp.unix.wizards:23667
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX does *not* fully support asynchronous I/O
Message-ID: <61281@lanl.gov>
Date: 27 Aug 90 22:22:36 GMT
References: <11576:Aug2503:18:3790@kramden.acf.nyu.edu>
Distribution: usa
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 25

From article <11576:Aug2503:18:3790@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> [...]
> I'm afraid Jim is right, though he drastically overestimates the effect
> of this failure on small machines. Let me explain.

True.  But many "small" machines aren't very small any more.  This will
increasingly be true.

> [...]
> Under UNIX, there's at least one big extra step. write(fd,buf,n) first
> *copies* the data to a buffer inside the kernel's space. This takes CPU
> time. Do you see now what Jim is complaining about?

Takes more than CPU time.  If the program is consuming and producing
data at (or exceeding) the maximum I/O rate, the buffers will always
be busy when I make a request.  I will, therefore, be forced to wait.
With real asynchronous I/O, I only wait when I need the next I/O to
have _completed_, not when I make the request.  This means that _none_
of the I/O will overlap user calculation in the UNIX style, while
_all_ of the I/O will be overlapped with genuine asynchronous I/O.

J. Giles

P.S. Dan:  I have been on vacation and will get to your email when I
catch up with other things.