Xref: utzoo comp.lang.misc:5435 comp.unix.internals:10
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc,comp.unix.internals
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <12023:Aug3017:24:1590@kramden.acf.nyu.edu>
Date: 30 Aug 90 17:24:15 GMT
References: <11576:Aug2503:18:3790@kramden.acf.nyu.edu> <27619@nuchat.UUCP> <861@dg.dg.com>
Distribution: usa
Organization: IR
Lines: 38

In article <861@dg.dg.com> uunet!dg!lewine writes:
> In article <27619@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
> > (For completeness I will note that to use this scheme intelligently
> > you must be able to discover the relevant properties of the memory
> > management implementation.
> 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.  

No. Steve's point was that on paged architectures, he can get a low-cost
speedup out of some programs without any change in semantics. This is a
worthwhile change.

Discovering memory managemment can be as simple as having a system call
getpage() that returns a char buffer taking up exactly one page. Any
code that understands this can take full advantage of asynchronous I/O.

> If you blindly map the page(s) containing "buf" out of the users
> address space you will map out other variables that the user may
> want.  It is not possible for the compiler to know that buf must
> be on a page by itself.  How could you implement your scheme?

So what if there are other variables on the page? The worst that happens
is that the page gets mapped out and then back in; on paged hardware,
this cost is negligible. The best that happens is that the program uses
getpage() and guarantees that it will wait for the I/O to finish on that
page.

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

---Dan