Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!Bruce.Hoult
From: Bruce.Hoult@bbs.actrix.gen.nz
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <1991Feb7.015048.15695@actrix.gen.nz>
Date: 7 Feb 91 01:50:48 GMT
References: <1991Feb4.210853.22139@odin.corp.sgi.com> <13754@lanl.gov>
Sender: Bruce.Hoult@actrix.gen.nz (Bruce Hoult)
Organization: Actrix Information Exchange, Wellington, New Zealand
Lines: 24
Comment-To: jlg@lanl.gov

Jim Giles writes:
>An Operating System which wants
>to last across several different machines and over a long time period
>should include (hooks at least) for asynchronous I/O.  If you have
>hardware where such a thing doesn't gain - disable it.  The user
>can go on blithly thinking it's there - and code accordingly.

Interesting you should say that, because that's almost exactly the situation
on the Macintosh.

The Mac file manager has always had async i/o, and it actually *does* async
i/o with floppy disks, serial ports, appletalk, and network mounted disks
(such as AppleShare).  You can code async i/o for local hard disks, but
the current SCSI manager (for reasons known only to Apple) actually
performs it synchronously.

I'm not, of course, arguing that async i/o on SCSI disks wouldn't be nice
(and SCSI has provision for it), but just that you can code for it now,
and it will work when/if it becomes available.
-- 
Bruce.Hoult@bbs.actrix.gen.nz   Twisted pair: +64 4 772 116
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"And they shall beat their swords into plowshares, for if you hit a man
with a plowshare, he's going to know he's been hit."