🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1547

UNIX does *not* fully support asynchronous I/O

#1547
From: Dan Bernstein
Date: Sat, 25 Aug 1990 03:18
41 lines
2706 bytes
In article <1990Aug21.223350.7595@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
> In article <60345@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> >From article <126800008@.Prime.COM>, by EAF@.Prime.COM:
> >> If your language I/O library is intelligent and you are reading sequential
> >> data, the language library will call on the OS to read the next disk 
> >> block into memory, often before it is required.
> >Not on UNIX it won't.  There is no system call for the library to use ...
  [ John talks about simple caching schemes ]

I'm afraid Jim is right, though he drastically overestimates the effect
of this failure on small machines. Let me explain.

Say a program computes some numbers. Computes them optimally, in fact,
leaving them in an array. Now it wants to write the array to disk.

If the operating system weren't in the way, the program would simply
call upon the disk device to copy the data---through DMA, of course---to
the disk.

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?

Of course, on most machines disk transfer is much slower than CPU
transfer, so once you've gotten rid of the disk seek by caching, any
further asynchronicity is silly. But Jim works with very fast disks, and
a lot of them at once.

mmap() is a partial solution: it does its job well and gets rid of the
extra step, but doesn't fit into the ``UNIX model'' as well as it could.
How do you use mmap() on a pipe, for example? If two programs are
communicating via a pipe, they should be able to write data and read it
with *zero* copies in the middle. Under standard UNIX, there are two
extra copies at least: one for read() and one for write().

I've proposed a solution: make a call analogous to writev() that uses
the iovecs directly. Introduce another call that says whether a
particular iovec has been written or not. Also introduce a way to wait
on this status, similar to select(). Similarly for reading.

---Dan
Technical Details
Message-ID: <11576:Aug2503:18:3790@kramden.acf.nyu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!kramden.acf.nyu.edu!brnstnd
References: <126800008@.Prime.COM> <60345@lanl.gov> <1990Aug21.223350.7595@esegue.segue.boston.ma.us>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: UNIX does *not* fully support asynchronous I/O
Message-ID: <11576:Aug2503:18:3790@kramden.acf.nyu.edu>
Date: 25 Aug 90 03:18:37 GMT
References: <126800008@.Prime.COM> <60345@lanl.gov> <1990Aug21.223350.7595@esegue.segue.boston.ma.us>
Distribution: usa
Organization: IR
Lines: 41
X-Original-Subject: Re: buffering, was Query