Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!peruvian.utah.edu!u-lchoqu
From: u-lchoqu%peruvian.utah.edu@cs.utah.edu (Lee Choquette)
Newsgroups: comp.sys.mac.programmer
Subject: Re: doing real work at interrupts
Keywords: driver
Message-ID: <1990Oct30.131140.10113@hellgate.utah.edu>
Date: 30 Oct 90 20:11:39 GMT
References: <1990Oct30.152816.2172@cs.umu.se> <2303@heavens-gate.lucid.com>
Organization: University of Utah CS Dept
Lines: 38

In article <2303@heavens-gate.lucid.com> pab@lucid.com (Peter Benson) writes:
>
> It seems like what is needed is a general mechanism whereby any sort of
> task can be initiated at interrupt level.  This would have to be done by
> apple, but the right thing to have is a call that effectively says "call
> this function with these arguments at the next possible opportunity."

How about opening a "device driver" that doesn't actually do any
reading or writing to a device, but has its "dNeedTime" flag set,
indicating the system should call its control routine at specific
intervals--or as often as possible if the drvrDelay word is zero.  The
system doesn't actually call the control routine until the application
calls SystemTask, but at that time you can go ahead and do all the
memory movement you want.  I believe you can even do drawing and
window management.

The Device Manager chapter (II-193) says that your control routine
should be interrupt-driven, but that apparently applies only to device
drivers that can be called asynchronously.  Since your driver isn't
really running a device, and since nobody will be calling it but
SystemTask, you don't have to worry about being asynchronous.

If you put your driver in the system heap, it should stay around until
the machine is shut down.  I have an example of a driver which I
install in the application heap whose only function is to perform
periodic actions, like the tasks you're talking about.  Given interest
I'll put it in postable form.

The main disadvantage to this scheme is that such drivers won't get
called when the application is not calling SystemTask or
WaitNextEvent, such as while it's busy reading a file, but in these
days of MultiFinder, applications which don't hog the processor but
let other tasks have time for housekeeping are becoming more and more
common.
Lee Choquette                        Internet: u-lchoqu@peruvian.utah.edu
3846 Barbara Wy                      Bitnet:   choquette@utahcca
Salt Lake City, UT  84124-2304       UUCP:     utah-cs!peruvian!u-lchoqu
(801) 581-8810, 278-0826