Why overlap I/O and processing? clutches...

[utzoo!decvax!harpo!eagle!mit-vax!masscomp!tjt]

It's certainly true that some form of read-ahead/write-behind
buffering is required for the I/O devices described by John Gilmore
(e.g. streaming tape drives), and I agree that making asynchronous
I/O available to user processes is probably the best to accomplish
this.  I think the biggest potential disadvantage of asynchronous I/O
is that the burden of maintaining adequate buffering for a device is
placed on the user program.  The epitomy of this is VMS (at least the
early versions -- I have not had to use VMS since the release 1.6
days) where most of the file I/O buffering appears in RMS, part of
each user process.  Although it was possible to use RMS to get very
high throughput by using lots of read-ahead/write-behind buffers, the
system defaults were pretty bad.  Also, the technique of making
system I/O asynchronous and using user libraries to make it appear
synchronous (while doing the necessary buffering) is very expensive
unless you also have the ability (like VMS) to share libraries
between programs.