Xref: utzoo comp.lang.misc:5432 comp.unix.wizards:23721
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX does *not* fully support asynchronous I/O
Message-ID: <12166:Aug3017:36:0590@kramden.acf.nyu.edu>
Date: 30 Aug 90 17:36:05 GMT
References: <1990Aug27.223445.4474@sco.COM> <29639:Aug2903:48:4290@kramden.acf.nyu.edu> <1990Aug29.155253.18634@chinet.chi.il.us>
Distribution: usa
Organization: IR
Lines: 24

In article <1990Aug29.155253.18634@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
> Does this have something to do with unix?

Yes. (As A. Lester Buck pointed out to me in e-mail, the functions I
proposed for truly asynchronous I/O are already in POSIX.)

> The usual concept of unix I/O
> is that something that is written to disk is likely to be read back and
> thus should live in the common buffer pool for a while.  

Ummm, no. The LRU philosophy tells us that something recently *written*
is likely to be *written* in the near future; something recently *read*
is likely to be *read* in the near future. That's the most important
reason that things are kept in buffers: it's stupid to make a one-byte
modification to a block when more bytes are probably on their way. A
second reason is so that writes can be scheduled to avoid disk seeks and
not keep the process waiting while the disk catches up.

Now it is true that pipes, for instance, are likely to be read very soon
after they are written. But pipes aren't inherently disk-based objects,
and if they're implemented purely in memory, asynchronous I/O means that
a pipe read-write takes zero data copies.

---Dan