Xref: utzoo comp.unix.misc:5 comp.lang.misc:5453
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwvax!persoft!gorgon!dag
From: dag@gorgon.uucp (Daniel A. Glasser)
Newsgroups: comp.unix.misc,comp.lang.misc
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Summary: RT-11 completion routines/RSX+VMS QIOs
Message-ID: <1990Sep04.014353.15085@gorgon.uucp>
Date: 4 Sep 90 01:43:53 GMT
References: <1990Aug29.170931.10853@terminator.cc.umich.edu> <31445.26dc0466@ccavax.camb.com> <1990Aug31.142906.26633@uncecs.edu>
Followup-To: comp.unix.misc
Distribution: usa
Organization: Perseus Reductions (Medusa Division)
Lines: 57

[was x-posted in comp.unix.wizards and comp.lang.misc]

In article <1990Aug31.142906.26633@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes:
>In article <31445.26dc0466@ccavax.camb.com> merriman@ccavax.camb.com writes:
>>Sure sounds like VMS QIO calls.
>Sounds like the Amiga's OS to me.  And UNIX doesn't do this?

Well, standard Unix doesn't do this.  VMS always has, so has RSX-11, and
to some degree, even RT-11.  The Amiga OS is a rather recent invention, and
appears to use this old tried and true technique.

For those not familiar with the QIO concept, a read or write QIO is issued
with a special call that allows the application to proceed and be notified
by either a signal (AST in VMS technology) or an event flag.  When the
application needs to use the buffer it either checks the flag or waits until
the signal routine is executed.  Another QIO can be used to determine the
number of bytes read/written, the error status, etc.

This extends beyond doing solicited buffered I/O to unsolicited I/O.
In Unix, when a program wants to do processing in the background while
waiting for keyboard input, it either forks a child to do one or the
other, or polls the tty for input.  Under RSX or VMS, the program attatches
to the keyboard, specifies an unsolicited input Asynch. System Trap (AST)
service routine and goes about its business.  When the user types a key,
the main thread of execution is suspended and the AST service routine is called
to handle the keyboard input.  When done, the AST service routine returns
and the interrupted background processing continues as if nothing has happened.
When you get the hang of it, this is a very simple way to write programs.
I miss this capability in Unix, but have simulated it many times with
fork and signal.

As an extension to Unix, I would suggest the following:

  int writea(int fileno, void *buffer, size_t buflen, void (*complete_rtn)());
  int reada(int fileno, void *buffer, size_t buflen, void (*complete_rtn)());
	where fileno is the file number, buffer is a pointer to the
	bytes to be written/read, buflen is the number of bytes to
	be written/read from/to the buffer, and complete_rtn points
	to a function to be called when the read/write is complete.
	Maybe there should be an additional parameter or two -- flags
	modifying the actions, and a parameter to be passed to the
	completion routines.  The completion routines should take as
	a parameter the result of the write/read.  These routines return
	a status which indicates whether the async. read/write request
	is valid or not.  Care should be taken not to read/write
	the buffer area until the completion routine is called.

Since these are not changes to the existing read/write system calls,
dusty decks would not be broken.  They could also not take advantage
of the new functionality.  (The above proposal is close to the RT-11
completion routine scheme.)

If this debate goes on much longer, I'd suggest that it get removed
from comp.lang.misc, since this is not a language depenent issue.
-- 
Daniel A. Glasser                       One of those things that goes
dag%gorgon@persoft.com                  "BUMP! (ouch!)" in the night.