Xref: utzoo comp.lang.misc:5422 comp.unix.wizards:23689
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <27619@nuchat.UUCP>
Date: 28 Aug 90 23:43:48 GMT
References: <126800008@.Prime.COM> <60345@lanl.gov> <1990Aug21.223350.7595@esegue.segue.boston.ma.us> <11576:Aug2503:18:3790@kramden.acf.nyu.edu>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Distribution: usa
Organization: Houston Public Access
Lines: 54

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.

(Note that such a call might be useful to a program that
wished to control its paging behaviour if it were written with
sufficient generality.)

The scheme will only provide asynchronicity in cases where the
return value for the read or write call is known early.  This
will be the case primarily for files, but other cases can be
made to take advantage of it.

The performance characteristics would be similar to using mmap
but would apply to programs written in normal unix style and
to dusty decks.  One must of course take some care in implementing
the scheme, and there are no doubt the usual raft of gotchas that
come up when doing anything involving memory management.  The
case of write(1,buf,read(0,buf,sizeof(buf))) is entertaining to
contemplate for instance.

Good performance with V7 file system call semantics.  Programs
work whether the feature is in the kernel or not and whether they
are written to take advantage of it or not.  I sure wish I
had thought of it a long time ago (like while the standards
were still soft).

I would appreciate any comments that wizards with more kernel
internals experience might have.  If I've rediscovered something
well-known again I think I shall slit my wrists.

(For completeness I will note that to use this scheme intelligently
you must be able to discover the relevant properties of the memory
management implementation.  This is nothing new for high performance
programs in a paged environment, but unless its been added recently
there isn't a standard way to do it.  Whether this is properly a
language or a system interface issue is best left to another debate.)
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"To learn which questions are unanswerable, and _not_to_answer_them;
this skill is most needful in times of stress and darkness."
		Ursula LeGuin, _The_Left_Hand_of_Darkness_