Xref: utzoo comp.lang.misc:5425 comp.unix.wizards:23700
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!umich!terminator!merit.edu!rsc
From: rsc@merit.edu (Richard Conto)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Keywords: Buffered I/O, paging, swapping, asynch I/O
Message-ID: <1990Aug29.170931.10853@terminator.cc.umich.edu>
Date: 29 Aug 90 17:09:31 GMT
References: <126800008@.Prime.COM> <60345@lanl.gov> <1990Aug21.223350.7595@esegue.segue.boston.ma.us> <11576:Aug2503:18:3790@kramden.acf.nyu.edu> <27619@nuchat.UUCP>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rsc@merit.edu (Richard Conto)
Distribution: usa
Organization: U of Michigan, Merit Network
Lines: 32

In article <27619@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
>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.
>
>A user program that is not aware of the subterfuge will then run
>along for some (probably short) time and trap on an attempt to
>refill or inspect the buffer.  It will then be blocked until
>the request completes.  A savvy program will do something else
>for as long as it can, then take a peek at the buffer when it
>has run out of busy work.  One would probably also provide
>(grudgingly, in my case) an explicit call for discovering the status.
 
A buffer is not necessarily aligned on a page boundary. And a page
may contain more than one variable.  The savvy program would have to
design it's data structures (including local variable arrangement, if
a buffer happens to be there) to be aware of whatever peculiar way
the complier lays out variables and whatever peculiar granularity the
OS has for pages.

Make it simpler. Have a routine that requests an I/O operation. Another
routine that can check it's status. A way of specifying a routine to be
called when the I/O operation completes might be yet another option.
I'm afraid that your idea adds unnecessary complexity (and system dependancies).
And using constructs like 'write(fdout,buf,read(fdin,sizeof(buf), buf))' is
asking for trouble when 'read()' returns an error condition.

--- Richard