Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple HD SC 80 does not support Asynch i/o.
Keywords: Hall of Shame entry?
Message-ID: <11623@dartvax.Dartmouth.EDU>
Date: 4 Jan 89 03:53:51 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu> <27318@ucbvax.BERKELEY.EDU>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 85

In article <27318@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>1.) Since I wrote the original posting and the test program I learned that
>the SCSI hardware on a MacPlus, anyway, does not support any kind of
>interrupt mechanism. This, at first glance, would seem to make it
>impossible, but it doesn't really (after all, the floppies do it.):
>

OK, that explains why the Apple HD SC driver does not appear to do
asynchronous I/O, sort of.  I believe Apple might be dropping the ball
on this one, however, in not insisting on at least some form of
asynchronous I/O in all device drivers to run under the Mac OS.  The
ability for a programmer to specify asynchronous I/O in such an easy
fashion as is allowed on the Mac is something which sets it apart from
other comparably priced systems.  You don't even have to establish a
"mailbox" before doing so!  (It is REALLY a pain to do asynch I/O on
some systems.)

It appears to me that asynch I/O is only widely used for "slow"
devices like the serial ports and the Sony disk driver.  It is just as
valuable a feature for "fast" devices, too.

>It may be that only clever programmers will use this to write superior
>application programs.  I'm not afraid of that.  I'm clever enough to
>compete, and I want those superior applications to use.
>

So people won't get the impression that asynch I/O is an esoteric
programming practice only suited for heavy-duty number crunchers,
allow me to give a few examples where it could come in handy for any
Macintosh program.

     Let's say you open and start to read/write file which you have
accessed from Standard File.  Assume the disk driver software gives
you a few thousand cycles to play with while it is seeking for disk
blocks in the file.  This is probably enough time to run through your
main event loop a couple times, and maybe even service the update
event generated by the appearance of the Standard File dialog.  If
your main event loop is smart enough not to interfere with the pending
I/O, then there are lots of things it could do.  This might not seem
like a lot, but if it allows you to keep your program's windows clean
for a fraction of a second longer than the other guy, it might just
make you look like a performance programming expert.  You can do this
right now with the floppy driver, so try it!

     How about a file conversion utility, like BinHex, or StuffIt, or
anything that reads in a file, does some conversion on it, then writes
out another file.  These are real handy, but when I am running one I
can't wait for it to get done.  If the disk driver gives back any
fraction of unused time to the application, which is then smart enough
to interleave the conversion process with I/O, then the user may be
spared a few seconds of boredom.  This is important, especially if the
conversion operation is a real important one like backups.

     Apple had a real good idea when they allowed the Device Manager
calls to specify asynchronous or synchronous I/O, in a fashion which
is easy to program.  They should have followed through with this idea,
making it clear to third party hardware developers that asynch I/O is
expected, and that any unused time belongs to the calling application.
Future devices will be capable of supporting this feature, but only if
programmers today make it clear that it is a necessary one.

     Of course, the Print Manager supports asynchronous I/O, and Apple
printer drivers make it REAL easy to take advantage of it.  All you
have to do is pass the Printing Code a pointer to your idle routine,
and the Print Manager will call it whenever it is waiting for the
serial port.  How many Macintosh applications actually do something
useful with their idle procedure, or even supply one?  Lots of them
don't even update their front window after the Job Dialog is closed,
and many use the idle time to do nothing but check for command '.'.
The screen display while most applications print is a lot less
appealing than it could be, given that the Print Manager gives you
time back when it is printing, and did so long before MultiFinder.
This makes such applications look unfinished to me.

     Maybe this is why we don't have more aggressive support of asynch
I/O on the part of Apple, that they sense that most programmers simply
couldn't be bothered with the "trouble" it takes to use it.

     Asynchronous I/O is very little trouble to use, considering all
the benefits, and I for one would be disappointed if it fell into
disuse because of lack of programmer interest.

Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755
(603) 643-4109
Graduate student.