UNIX semantics do permit full support for asynchronous I/O

[Steve Nuchia]

In article <555 at siswat.UUCP> buck at siswat.UUCP (A. Lester Buck) writes:
>As to Steve's idea, it has a certain elegance to recommend it.  But its
>practical value is low.  Sure, it can be made to have full Unix semantics,

Hmm.  What ever happened to aesthetic value having some measure of
parity with "practical" value?

To update everyone on my thinking, there have been two serious
(in my view) objections raised.  The fact that at the extrema
of system performance requirements my assumption of a paging
environment is false is the most damaging, and probably is sufficient
to relegate the whole idea to the scrap-heap.  Secondly, the cases
in which the return value (especially for read) cannot be predicted
productively, though few, are important enough to cast serious
doubt on the sufficiency of my scheme.

>What may be difficult to understand at this point, when Unix has not had a
>standard asynchronous I/O facility, is that we will program _differently_

An excellent point, one we would all do well to keep in mind.  I would
have added to Lester's list of examples the event-driven style imposed
by modern user interface construction.

>The POSIX.4 asynchronous I/O facilities are moving toward final ballot and
>present a rich set of asynchronous I/O primitives.  These include the

It is precisely this "rich set" of "primitives" (!!!) that I am
striving to avoid.  If one may, as you suggest, learn something
by examining MVS and VMS and all thos other UPPER CASE operating
systems, one of those things should be that a proliferation of
system interface mechanisms (calls, whatever) is Not Good.

>The process can learn of I/O completion in at least four ways:  1) return
>codes written into the process' asynchronous I/O control block, 2) receiving
>a completely asynchronous "fixed" (queued, tagged) signal/event which runs a
>handler, 3) synchronously suspending for I/O completion (iosuspend), or 4)
>synchronously suspending or polling for the signal/event posting I/O
>completion.  [Suspending is familiar, but the committee added polling, where

AAAARRRRRRRGGGGHHHH!!!!!

The time has come to wander in the desert for a while, I think.

For what its worth, I've solidified my thinking on the completion
discovery mechanism I hinted at in my original posting.  It is a
general purpose VM interface call with the following properties:

	int ret = vm_avail ( base, len, mode )
		char	*base;	/* user virtual address */
		int	len;	/* extent of block in bytes */
		int	mode;	/* read or write or both */
	
	ret = number of continuous bytes, starting at base,
		available for the specified access mode(s)
		without faulting.

	As a side effect, every page in the block is "scheduled"
	to become available, as if an access attempt had been
	made to it.  This may involve faulting a page in from
	disk, making a copy-on-write copy, or whatever.
	
	vm_avail will not block, but it may take an arbitrary
	amount of time (linear in len) eg for zero-fill or block copying.

This could be used, if one implemented my original asynch-io
scheme, to check for (incremental!) read/write completion.  It could
also be used to read-ahead a memory mapped file.  A real-time program
that had some portions of its image pageable could also use it to
avoid taking page faults.

Aren't I just full of it?  :-)
-- 
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_