Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.misc Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: Date: 5 Sep 90 14:11:25 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> <8CK5.RE@xds13.ferranti.com> <59247@bbn.BBN.COM> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Distribution: usa Organization: Xenix Support, FICC Lines: 15 In article <59247@bbn.BBN.COM> pplacewa@bbn.com (Paul W Placeway) writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > < ... 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. > Unless your "disk" is RFS and the remote machine crashes, or soft > mounted NFS and any one of about a zillion things happens... This is an optimisation. You don't have to enable it for network file systems, or raw disk devices, or whatever else. Most programs can't recover from a disk fault, or a network fault, so blowing the program away when you fault to the bogus page is perfectly legitimate. Programs that *can* recover can either be run in a lower performance mode or be rewritten to handle this error. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com