Xref: utzoo comp.lang.misc:5444 comp.unix.internals:17 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!rutgers!mcnc!rti!dg-rtp!hunt From: hunt@dg-rtp.dg.com (Greg Hunt) Newsgroups: comp.lang.misc,comp.unix.internals Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: <1990Aug31.200440.13797@dg-rtp.dg.com> Date: 31 Aug 90 20:04:40 GMT References: <11576:Aug2503:18:3790@kramden.acf.nyu.edu> <27619@nuchat.UUCP> <861@dg.dg.com> <12023:Aug3017:24:1590@kramden.acf.nyu.edu> <1990Aug31.190751.12522@dg-rtp.dg.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hunt@dg-rtp.dg.com Distribution: usa Organization: Data General Corp., Research Triangle Park, NC Lines: 65 In article <1990Aug31.190751.12522@dg-rtp.dg.com>, eliot@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@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.