Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!cluster!bruce
From: bruce@cs.su.oz (Bruce Janson)
Newsgroups: comp.arch
Subject: Re: Async system interface
Message-ID: <1995@cluster.cs.su.oz.au>
Date: 6 Feb 91 08:18:14 GMT
Sender: news@cluster.cs.su.oz.au
Lines: 65

In article <13772@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>.. The I/O call (below, RW
>stands for _either_ the read or the write system call) should be
>something like the following:
>
>RW(fd,nw,buf,da,aflag,handle)
>..
>da - logical disk address (relative to beginning of file) for I/O
>   transfer.  lseek() is redundant and in this model would disappear.
>   If da is -1, transfer is sequential from previous request.
>..
>handle - this is a pointer to an I/O completion routine in the user's
>   process.  This routine is called when the I/O requested has been
>   done.  If this pointer is null, no user function is called. (This
>   routine is called even if synchronous I/O was requested.)
>..

Jim,
    Above, you have outlined part of an async I/O interface.  But there
are some issues that I am still not clear about that perhaps you might
like to clear up.
    When you say "transfer is sequential from previous request" do you
mean the previously issued request or the previously completed request?
More generally, in what context does the I/O get done?
In what context does the I/O completion function run?  Are the machine
operations of either the I/O copy or the completion function interleaved with
those of the rest of the program or is the "rest of the program"
suspended while the I/O and its completion routine run.
Is the contents of the area of memory pointed to by "buf" updated
atomically with respect to the process?
Is the I/O completion routine called with any arguments?
Can the I/O completion routine call sleep()?  Where does a longjmp()
take me from within such an I/O completion routine?  What does a setjmp()
do when executed from within such an I/O completion routine?  How about calls
to the signal() family of routines and can the I/O completion routine
be interrupted by an incoming signal?  What exits when I call exit()
from within an I/O completion routine?  What happens when the main
program calls exit() while there are still I/O requests outstanding?
What happens if my process calls close() on an fd that is still
associated with outstanding async I/O?
How many concurrent outstanding I/O requests can my process have at
the one time and can I prioritise and/or schedule them?
Can a process enquire as to the status of a particular
outstanding I/O request and if so, what naming scheme should it use
to refer to the I/O request of interest.  How do I terminate an
outstanding I/O request prematurely?  Can an I/O completion routine
make further async I/O calls itself?
    It is possible to devise answers for all of these questions.
And async I/O does exist in various operating systems so answers must
have been devised.  However, after considering these questions I might
conclude that async I/O would need to bring with it some very
significant advantages to offset what appears to be a more complex model.

Cheers,
bruce.

Bruce Janson
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W., 2006
AUSTRALIA

Internet:	bruce@cs.su.oz.au
Telephone:	+61-2-692-3272
Fax:		+61-2-692-3838