Xref: utzoo comp.lang.misc:5427 comp.unix.wizards:23709
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <61535@lanl.gov>
Date: 29 Aug 90 20:46:54 GMT
References: <27619@nuchat.UUCP>
Distribution: usa
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 23

From article <27619@nuchat.UUCP>, by steve@nuchat.UUCP (Steve Nuchia):
> On the subject of asynchronous I/O in Unix:  I've come up with
> what I consider a rather slick way of making it fit neatly
> into Unix's way of doing things:
> 
> Have read(2) and write(2) calls map the pages containing the buffers
> out of the user address space and return immediately.  Once the
> data have been copied (DMAed?) to/from the buffers, map the pages back in.
> [...]

Yes, this will work.  I believe that MACH already does this.
Unfortunately, this idea has two problems: 1) not all machines are
paged/segmented; 2) not all I/O requests are a multiple of the
pagesize.  The first problem is more severe - hardware designers avoid
pages/segments when designing for speed.  The extra hardware overhead
is 10% speed or about that for extra hardware cost.  So they are
avoided (Crays don't have pages or segments).  The pagesize problem
just means that you'd have to map out more memory than is actually
involved in the I/O request.  This means that the user might get
blocked on memory that is really perfectly safe to access - a minor
source of slowdown.

J. Giles