Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: VMS vs. UNIX file system
Message-ID: <1572@ficc.uu.net>
Date: 21 Sep 88 20:48:02 GMT
References: <411@marob.MASA.COM> <3597@encore.UUCP> <3438@crash.cts.com> <10105@eddie.MIT.EDU>
Organization: SCADA
Lines: 41

In article <10105@eddie.MIT.EDU>, jbs@fenchurch.MIT.EDU (Jeff Siegal) writes:
> I think a more fundamental advantage of the VMS I/O system is that
> QIO's can be queued to execute asynchronously (similarly for RMS
> operations).  An AST (software trap) is delivered to your process when
> the I/O completes.  The AST tells you which I/O operation completed,
> and the error status.

I really really wish UNIX supported this. At home I use AmigaDOS, and
it lets you do the moral equivalent:

	Issue a write by sending a message to the file's handler task.
	Do something else.
	Either:
		get a software interrupt when the I/O completes,
	or:
		wait on a signal bit (event flag, for DEC types).

Since every outstanding I/O has a signal bit, you can always wait for
whatever combination of events you want.

There's nothing in the UNIX file model that should prevent this, and
in fact the signal bit for a FD could be the FD.

	printf("Hit any key to abort.\n");
	if(aread(0, &ch, 1) && aread(fd, addr, nbytes)) {
		bitmap_t bits = (1<