[no subject]

     IMPORTANT

     After a handle has been dereferenced, certain system calls or
     toolbox calls might cause memory compaction, which would
     then make the pointer to the block invalid.  In that case, your
     application must dereference the handle again.  However,
     compaction won't occur unexpectedly; that is, toolbox calls
     made from interrupt handlers cannot force compaction.  This
     means that unlocked blocks can safely be dereferenced so long
     as no system or toolbox calls are made between the dereference
     and the use of the handle.

It's not an obscure secret.  It's an explicit statement that has always
been in the Memory Manager documentation.

> Although... No, it wouldn't work. If a context switch were to occur
while I
> was using the block some other process could make it move around.
> 
> Guess I'll just keep on doing it the way I always have.

"MultiFinder" style multitasking is no problem, since context switches
happen only on certain calls to GetNextEvent.  Memory can safely move,
because every process that is not in control has simply not yet returned
from a GetNextEvent toolbox call that it made.  When it finally returns,
memory is allowed to have moved.

If you are using a 3rd-party environment that allows context switching at
interrupt time, the only SAFE thing is for that environment to *never*
allow memory compaction (by permanently incrementing the $E100CB flag),
or to make sure that all code running when context switching could occur
is assuming that unlocked blocks can move at any time.

I have -not- been following GNO closely, so please correct me if I'm
wrong about any of the following.  GNO does not allow a context switch
while a toolbox call or GS/OS call is in progress, so there is no problem
with the toolbox or GS/OS having its handles moved out from under it. 
The last I heard, GNO was not preventing memory compaction, so the
implicit (or is it made explicit now?) assumption is that all processes
assume their unlocked blocks can move at any time.

If you want to run arbitrary GS software in a nonstandard environment,
either (1) you cross your fingers and hope it works, (2) you change all
your software to conform to newly-invented rules, or (3) nonstandard
environments have to preserve the existing rules.

For example, if you run the Finder under GNO, the last I heard we are at
(1), and one of these days I hope we'll be at (3).

David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II System Software Engineer         |   P.O. Box 875
Internet:dlyons@apple.com                 |   Cupertino, CA 95015-0875

My opinions are my own, not Apple's.