Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!agate!ronzoni!lippin
From: lippin@ronzoni.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM Unlocks handles (was Re: How to Argue Technical Points)
Message-ID: <1989Dec6.063737.23125@agate.berkeley.edu>
Date: 6 Dec 89 06:37:37 GMT
References: <2744@dogie.macc.wisc.edu> <3838@atr-la.atr.co.jp> <32977@ucbvax.BERKELEY.EDU> <3842@atr-la.atr.co.jp>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 68

Recently alain@atr-la.atr.co.jp (Alain de Cheveigne) wrote:

>In article <32977@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu
>(David Phillip Oster) writes:

[Good stuff deleted]

>>If you use a style like:
>>	 HLock(handle);
>>	 OneSystemCall();
>>	 HUnlock(handle);
>>or even better:
>>	 temp = (**hand).field;
>>	 SystemCall(&temp);
>>	 (**hand).field = temp;
>>you'll never have to worry about the ROM unlocking things.

>I run into two problems with these schemes:
>
>a) The structures I use are deep.  Concretely: my program uses lots of
>windows, which the user can create and dispose of in any order.  Data
>is attached to each window in a relocable block, referred to by the
>window refCon, and that block in turn refers to other relocatable data
>and to another window (itself with data).  So reference to a given
>field is done through many levels of indirection, most of them
>relocatable...  I can't imagine locking and unlocking all this stuff
>at every system call, so this rules out the first scheme.
>
>b) Several of my data fields are big: text, signal arrays, and bit
>images used by bitmaps (yes, I'm aware of the dangers of relocating
>these...).  I don't want to copy the data each time it is used in a
>system call.

Most of the VAR-parameters the system wants are no larger than a long
word.  If these are located in relocatable blocks, I recommend using a
shadow variable on the stack for the call.

In the case of larger parameters by reference, I recommend locking the
block first, and restoring its restoring its state afterward.
HGetState/HSetState is sometimes better, but most handles are only
locked only in extreme circumstances, and HUnlock will suffice for
them.  Note that only the block containing the parameter needs to be
locked; "parent" blocks are free to slide around.

The other reason for locking a handle is so that you may carry around
a dereference to it.  In general, I avoid passing such a handle to any
major subroutine, be it my own or part of the operating system.  With
the obvious exceptions, I never pass a locked handle to the OS.  When
it becomes necessary to do so, I usually will unlock the block for the
duration of the call and recompute the dereference afterward.  Or
consider getting rid of the dereference entirely.

These rules won't cover every instance, but I find that the exceptions
are few and far between.

Finally, a note on MoveHHi -- this call is easy to overuse.  It's only
an advantage if a block is going to remain locked for a respectable
length of time; in particular, only when there's a chance of
significant memory allocation while the block is locked.  If used when
not necessary, it wastes time with frivolous heap shuffling.  Since
I avoid keeping handles locked for such periods, I use MoveHHi very
sparingly.

					--Tom Lippincott
					  lippin@math.berkeley.edu

	"It's a poor sort of memory that only works backwards."
					--The Red Queen