From: REEKES@applelink.apple.com (Jim Reekes)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Deferred Tasks - What can I do?
Date: 9 Oct 92 21:05:30 GMT
Followup-To: comp.sys.mac.programmer
Organization: Apple Computer, Inc.

In article <1992Oct8.231012.1588@cs.tulane.edu>, mandel@tmc.tulane.edu
(Jeff E Mandel) wrote:
> 
> In article <REEKES-081092123045@90.10.20.67> Jim Reekes,
> REEKES@applelink.apple.com writes:
> >Both a VBL and a Deferred Task are considered interrupt code.  Neither
> >can make calls to the toolbox, allocate memory, etc.
> >
> 
> While I understand what you mean, this is not what you are saying. You
> cannot call anything which isn't reentrant, or which presumes that an
> unlocked block is where the handle says it is, etc., but that doesn't
> mean you can't call anything in the toolbox, or even allocate memory.
> There exist techniques whereby you can preallocate a private heap, for
> which you write all of the HeapZone functions, which can be made to
> function within the constraints of interrupt-driven code. Now, most folks
> don't need this, because usually interrupt-driven code does the same
> thing over and over again, and you can get by with just allocating a
> suitably large number of queue elements and managing a free list (like
> the nonpaged dynamic pool, for you VMS folks).  You can also do a a
> number of things which lead up to screen output from interrupt-driven
> code, but since it is a major pain to keep track of where things are,
> it's not worth the trouble (I know, I once wrote a preemptive
> dual-tasking executive which allowed me to simulataneously run a
> real-time controller and the user interface, except it bothered the users
> that it would draw graphs through the menus, and they'd subsequently be
> sucked back up into the menubar! (the graphs, not the users)).
> 
> Since I probably planted the idea in Pete's head about Deferred Tasks,
> the best thing I can suggest is to decide whether the blocks you need at
> interrupt time can be of a fixed size, or not. If not, you've got to
> write something that manages the memory you preallocate, and probably
> guard the code with a spinlock, as it may get reenterred. Plan on long
> sessions in MacsBug. If it can be of fixed size, then create two OS
> queues, one which contains a list of free blocks, and the other is used
> as your private event queue. It is possible to do this with only one
> queue (this is how the event queue works, but it doesn't permit you as
> much flexibility in priority handling).

While you think you know what I mean, you really don't.  I was avoiding
a long discussion about all the hows and whys.  It's much more truthful to
state that you cannot call any toolbox calls.  There are few that can be,
and Apple doesn't document them because we couldn't.  The list of
exceptions
is far too great.  Besides, the movement is to avoid interrupt code
entirely.

Here's a little more data about the issue.  Not only is allocating
or moving blocks in the heap illegal during interrupt, you cannot call
routines that are non-reentrant.  This just about excludes all of the
toolbox.  The Mac toolbox uses lots of low memory globals, much more than
that Inside Mac ever talks about.  Because of this global state
information,
you cannot call a routine that depends on such a globals.

Furthermore, some of these globals are swapped during a tasks context.  
For
example, FrontWindow refers to the global WindowList.  This global is
swapped for
the current process.  Even thou FrontWindow doesn't move or allocate
memory,
nor does it have a reentrancy problem, but it cannot be called a interrupt
level.

Because of this last issue, things get really sticky.  We don't have a list
of which globals are swapped for a task, and it changes for the many
releases
of the MultiFinder/Process Manager.  This is part of the reason we cannot
document entirely which calls cannot be called at interrupt level.  We do
attempt to provide a list of the ones we promise to be safe, such as
StripAddress.

-----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S