UNIX semantics do permit full support for asynchronous I/O

[Greg Hunt]

In article <1990Aug31.190751.12522 at dg-rtp.dg.com>, eliot at dg-rtp.dg.com
(Topher Eliot) writes:
>
> 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
>

Yes, I can.  Under Data General's AOS/VS OS, I wrote a program that
read blocks from tape drives and checked the sizes of the blocks read.
The program was for verifying that labeled backup tapes were
physically readable.

The header label on the tape contained buffersize information which
the program used to read the data blocks.  As each block was read,
the size of the read returned by the OS was checked against the
buffersize to ensure that full buffer reads were done.  It also
counted the number of blocks read.  It discarded the contents of the
read buffer without looking at them.

The trailer label on the tape contained block count information that
was written by the OS.  The OS's block count was compared against the
block count seen by the program.

All of these checks were only to ensure that the tape could be
physically read.  Using it eliminated ALL bad backup tapes that I was
encountering.  Sometimes I found that I could write a tape, but not
read it again.  Tapes that could not be verified by this program were
discarded.  The program did nothing to ensure that the tape could
be logically read by the load program used to restore files, so it
did nothing to guard against bugs in the dump/load programs
themselves.

I have yet to port the program to DG/UX to verify UNIX backup tapes in
a similar manner.  I believe the program could be made to serve a
similar purpose, but I'd probably have to change the header/trailer
handling since AOS/VS uses ANSI standard tape labels and I don't think
that UNIX does.

Does this example meet the behavior that you were wondering about?  It
may be a specialized use of the results of a read and not be
representative of what applications-level software does.

--
Greg Hunt                        Internet: hunt at dg-rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC       These opinions are mine, not DG's.