Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!usc!apple!fox!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need info on multitasking capabilities on the mac
Message-ID: <24454@cup.portal.com>
Date: 25 Nov 89 03:44:48 GMT
References: <6391@tank.uchicago.edu> <9072@hoptoad.uucp>
Organization: The Portal System (TM)
Lines: 59

Tim Maroney writes:
> I wonder how they do that.  Can anyone provide any information?  My
> first thought was to schedule your file transfer protocol off the
> vertical retrace manager, but your tasks don't get called when you're
> switched out.  Perhaps there's a loophole with the Time Manager that
> allows that, but the Time Manager is broken in a number of OS releases
> and really can't be relied on.  You can't patch traps to do it because
> the patches only apply to your own application.  Hmm.  You could always
> install your own clock interrupts or something similarly awful, but

Even if they manage to get something like this to work, there are still
problems.  At some point the file transfer protocol is going to have
filled all the buffers it has available and is going to need to do
some file I/O.

Is it safe to do file I/O from an interrupt routine?  I doubt it.  Even
if the File Manager can handle it, the SCSI Manager is not supposed to
be used this way.

> forget compatibility!  Perhaps installing a driver in an empty unit
> table slot would work, but I doubt drivers get any time when
> applications don't.  Maybe if the driver installs the retrace routine,
> it will get called in any context?

People who write drivers for SCSI Ethernet adaptors run into this sort
of problem.  If the driver sets dNeedTime to get run time to check the
device for incomming packets, it hangs up when the application does
a synchronous read call.  AppleShare likes to do these, so if the driver
is using this mechanism, it fails to work with AppleShare.

A vertical retrace routine installed by the driver does appear to get
called all the time.  Of course, then it has the problem of using the
SCSI Manager at interrupt time.  The approach we took with the Dove
FastNet SCSI driver was to use a vertical retrace routine, but to be
very careful to try to avoid calling the SCSI Manager if there is any
indication that something else ( e.g., a SCSI disk driver ) could be
using the SCSI Manager at the moment.  It seems to work OK.

This problem also shows up with removable media SCSI disk drives.  The
driver needs to check the drive to see if the media has been inserted.
The obvious way is to use dNeedTime.  However, dNeedTime events do not
get called during the "Please insert the disk named Spam" dialog, which
is of course the most important place you need to recognize when a disk
has been inserted!

There are two approaches that driver writers use here.  One is to have
a vertical retrace task.  This is what I tend to use.  I use dNeedTime,
but have a vertical retrace task too, and if the vertical retrace task
sees that a couple of seconds have passed without dNeedTime events
happening, it checks for a disk having been inserted.  It makes the
same sort of safety checks that I do with FastNet SCSI, so it should be
safe.

The other approach that is often used is to patch a trap.  There is one
trap, which I forget, that is called repeatedly while the "Please insert
" dialog is up.  The driver patches this trap and the patch code checks
for the disk having been inserted before jumping to the original code.

						Tim Smith