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<