From: Mark.R.Valence@dartmouth.edu (Mark R. Valence)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Memory Manager-safe Deferred Tasks - A Proposal
Date: 16 Oct 92 03:15:20 GMT
 <1992Oct14.141151.5753@cs.tulane.edu> 
 <1992Oct14.133359.2786@dartvax.dartmouth.edu>  
 <1992Oct15.141437.22887@cs.tulane.edu>
Organization: Dartmouth College, Hanover, NH
X-Posted-From: InterNews1.0a5@newshost.dartmouth.edu

I wrote:
>Why not just patch NewHandle?  Then you can be guaranteed that it is
>safe to allocate memory, move the heap around, etc. because someone is
>already doing it.  You need a flag to make sure you don't re-enter your
>task scheduler, but that is easy.  What's more, you can implement the
>"Hz" functionality you originally wanted.  Here it is:
>

In article <1992Oct15.141437.22887@cs.tulane.edu>
mandel@tmc.tulane.edu (Jeff E Mandel) writes:

> I believe this is not the best solution. There are many traps which move
> memory, and NewHandle is only one. To make this approach work, you'd have
> to head patch every trap which can move memory. Even if you wanted to do
> that much patching (Which is certainly feasible), you still have the
> problem that you are depending on someone to call one of the
> memory-moving traps before your deferred task is delivered. What if
> you're waiting for an IO request to complete? Or in a long computational
> loop? the deferred task is frozen out.


No, you don't have to patch every trap that can move memory (jeez,
that's quite a few!).  When ANYONE, including the routines in ROM,
calls NewHandle, they are basically saying "I don't care if memory
moves."  So, just patch NewHandle, and you have the necessary
conditions for a DTHz Manager.  You are right that you would then be
relying on someone else to call NewHandle, but that is going to be a
drawback of any scheme.  Even if you trap every memory moving trap,
what if my app is in the middle of its save loop (repeatedly calling
_Write, which can't move memory).  Well, I guess you could check to see
if it was an ASYNC write, and only do your DTHz stuff if the call was
ASYNC.  Anyway, the point is that the NewHandle scheme will work pretty
well (oh, go ahead and augment it with patches on NewPtr and
NewTempHandle).  Remember that NewRgn, GetResource, etc. call
NewHandle.

One test:  do an atb on NewHandle in MacsBug, and then try to get
anything done.  Even pulling down a menu gets it (you have to move the
mouse, though, so that some call is made that eventually gets down to
calling NewHandle).  The hard one is moving a window.  I guess a trap
on _DiffRgn will get the job done in this case.  Kind of ad hoc, but
you aren't writing System software here (if you were you wouldn't have
to worry about these hacks).

Here's a new idea:  replace the A-trap interrupt, have your handy
"these traps move memory" table on hand, and then do the DTHz tasks
when appropriate.  It would have to be done right (for speed), but it
should work, after all you are in WAY before the OS, down to the bare
bones CPU.  Neat-o.

> >Honey?  Do you smell smoke?
> I don't know, dear. But doesn't that door feel awfully warm?

I've got the best asbestos suit available:  Long, specialized post that
only you and I read, all others do the 'K' thing.

Mark.
Newsgroups: comp.sys.mac.programmer