UNIX semantics do permit full support for asynchronous I/O

[Richard Conto]

In article <27619 at nuchat.UUCP> steve at 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