Xref: utzoo comp.lang.misc:5434 comp.unix.internals:9
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.misc,comp.unix.internals
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <8CK5.RE@xds13.ferranti.com>
Date: 30 Aug 90 20:05:15 GMT
References: <126800008@.Prime.COM> <60345@lanl.gov> <1990Aug21.223350.7595@esegue.segue.boston.ma.us> <11576:Aug2503:18:3790@kramden.acf.nyu.edu> <27619@nuchat.UUCP> <861@dg.dg.com>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Distribution: usa
Organization: Xenix Support, FICC
Lines: 18

In article <861@dg.dg.com> uunet!dg!lewine writes:
> That last remark defeats your entire suggestion.  If I have to
> "discover the relevant properties of the memory management 
> implementation", all dusty decks will fail.  

You only have to do this if you want to get some additional
performance. It should still work regardless.

> 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!

Well, it's an assumption made for write() anyway. For read() you can just
treat it like any disk error on any other faulted-in page and blow off the
process. Disk errors are a very rare occurrence, and almost always require
human intervention anyway. Any other return value for read is known
ahead of time.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com