UNIX semantics do permit full support for asynchronous I/O

[Topher Eliot]

In article <12023:Aug3017:24:1590 at kramden.acf.nyu.edu>,
brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
|> 
|> > Also the read() and write() functions return the number of
characters
|> > read or written.  How do you know this before the read() or
write()
|> > completes?  Do you assume that all disks are error free and never
|> > fail?  That is a poor assumption!
|> 
|> So what? read() and write() already return before data gets written
out
|> to disk; assuming that you see all I/O errors before a sync is the
poor
|> assumption! This is irrelevant to the issue at hand.

I think this point very well covers the case of writing:  if you want
to be sure it really got to disk, you need to do an fsync(), and even
then I'm not sure you can be sure (doesn't the fsync just *mark* the
buffers for writing out?).  We could certainly arrange for fsync to
block until everything is really on disk.

But consider the reading case.  Here, we could tell the process how
many bytes it had "gotten" (was going to get), even if it was less
than the process had requested (presumably the kernel knows how big
the file is, without having to read all those bytes off disk).  The
application then might do something *other than examining the bytes
it just "read"* based on this knowledge of a "successful read".  If
the disk then fails (or the net fails, or whatever), the application
would have acted incorrectly.  Moreover, instead of the application
learning about the failure by getting -1 back from a read call, it
will learn about it by receiving a signal or some such.

So, can anyone think of an application that behaves in this manner
(i.e.  acts upon the return value from a read by doing something
important, that does not involve examining the read buffer)?  I can't.
Perhaps more significant is the issue of the application not getting a
-1 back from the read call.

--
Topher Eliot
Data General Corporation                eliot at dg-rtp.dg.com
62 T. W. Alexander Drive               
{backbone}!mcnc!rti!dg-rtp!eliot
Research Triangle Park, NC 27709        (919) 248-6371
Obviously, I speak for myself, not for DG.