Xref: utzoo comp.lang.misc:5423 comp.unix.wizards:23690
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!husc6!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX does *not* fully support asynchronous I/O
Message-ID: <29639:Aug2903:48:4290@kramden.acf.nyu.edu>
Date: 29 Aug 90 03:48:42 GMT
References: <1990Aug21.223350.7595@esegue.segue.boston.ma.us> <11576:Aug2503:18:3790@kramden.acf.nyu.edu> <1990Aug27.223445.4474@sco.COM>
Distribution: usa
Organization: IR
Lines: 26

In article <1990Aug27.223445.4474@sco.COM> seanf@sco.COM (Sean Fagan) writes:
> In article <11576:Aug2503:18:3790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Say a program computes some numbers. Computes them optimally, in fact,
> >leaving them in an array. Now it wants to write the array to disk.
> >If the operating system weren't in the way, the program would simply
> >call upon the disk device to copy the data---through DMA, of course---to
> >the disk.
> Uhm, *where* is it going to put it?
> Or does the user program just automagically know which sectors on the disk
> are free to write in, and, of course, it's going to up date the inode
> information properly, and all directory information.

Who cares? It can use any disk management scheme it likes. This is
absolutely irrelevant to the issue: the time to update, say, the inodes
is at most a fraction of the time it takes to copy a large block of data
from one place in memory to another.

> Having worked on an OS that does to asynchronous I/O quite well (NOS, for
> those who don't read comp.arch 8-)), it's a bit different from what brnstnd
> says.

I was describing how asynchronous I/O works when there's no OS in the
way. You start talking about how a particular OS does asynchronous I/O.
``It's a bit different''---``No shit, Sherlock!'' RTFABYFU.

---Dan