Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!mtxinu!taniwha!paul
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple HD SC 80 does not support Asynch i/o.
Keywords: Hall of Shame entry?
Message-ID: <315@taniwha.UUCP>
Date: 5 Jan 89 23:41:37 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu> <872@lts.UUCP>
Reply-To: paul@taniwha.UUCP (Paul Campbell)
Organization: Taniwha Systems Design, Oakland
Lines: 44

In article <872@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes:
>Umm... that was the point.  Apple *did* build Async I/O into the
>system, it's just that their SCSI disk driver is incapable of
>supporting it.  A/UX, last I knew, didn't support it at all, just like
>most UNIX systems (well, they might have put in support for async I/O
>for sockets using SIGIO, but that's a special case).


Like most unixes A/UX doesn't allow processes to make mac-style async IO
requests, but it does do async SCSI IO in the kernel (ie while process A
is waiting for a read, process B can do other processing). It doesn't
just stall the whole system in a loop waiting for a SCSI device to
do a seek and transfer. Also like most other unixes it does block read ahead
on file accesses (ie when you read block #4 in a file it will read ahead
block #5 while you are processing block #4), this also happens asynchronously
so you do get the general effect. On writes IO is buffered in the block
cache giving a similar effect. Also if you have multiple disks that support
disconnect/reconnect it can start a transfer on one disk, then the other
then reconnect to them when the interrupt back to say that the seeks/transfers
have completed (of course the transfer across the SCSI from the controller's
buffer still has to be done by the processor).

For other than disk IO you can do the equivalent to async IO in many systems
that have BSD select() (including A/UX), between this and kernel buffering on
input and output you get the equivalent functionality (when you do your own
async IO in a Mac (or Dec or ...) style system you end up spending all your
time playing with buffers anyway). You do end up structuring  your code VERY
differently (the AppleTalk package CAP from Columbia is a very good example).

I suspect that the reason that the Apple MacOS SCSI driver isn't asynchronous
is that it was originally written on a system where it couldn't be (MacPlus)
and that it would probably need a complete rewrite to work both on systems
where one set of hardware supports interrupts and one doesn't (I guess you
would end up with different drivers .... but then the driver is on the disk
so you couldn't move the disks around ....). By the way the IWM doesn't generate
interrupts either, I guess it probably uses VBLs while the hardware is seeking.

		Paul

-- 
Paul Campbell			..!{unisoft|mtxinu}!taniwha!paul (415)420-8179
Taniwha Systems Design, Oakland CA

 	"Read my lips .... no GNU taxes"