Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!kddlab!atrpost!atr-la!alain
From: alain@atr-la.atr.co.jp (Alain de Cheveigne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM doesn't unlock Handles (was: ROM unlocks Handles). LONG
Message-ID: <3888@atr-la.atr.co.jp>
Date: 27 Dec 89 01:01:32 GMT
References: <3875@atr-la.atr.co.jp> <4525@helios.ee.lbl.gov>
Organization: ATR International,Japan
Lines: 59
In-reply-to: beard@ux1.lbl.gov's message of 26 Dec 89 18:01:15 GMT


In article <4525@helios.ee.lbl.gov>$@$G(Jbeard@ux1.lbl.gov (Patrick C
Beard) writes:
>In article <3875@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de Cheveigne) writes:
[...]
>>Another way to avoid locking is to use a temp variable, as recommends
>>tim@hoptoad.uucp (Tim Maroney):
>>>Handle h = NewHandle(WOMBAT_SIZE);
>>>(*marsup)->wombat = h;
[...]
>>This scheme was recommended by many, and emerged as the best solution
>>for short fields.  But it isn't obvious what to do if the field is
>>large: a string, or an array, or data for a BitMap or PixMap.
>
>Now wait one second.  We are talking about _Handles_.  The overhead required
>to keep a temporary copy of a Handle, regardless of how large the allocated
>memory block is, is 4 bytes!  Therefore, your analysis is incorrect.  You
>would never need more than one temporary handle variable to keep track of
>any size field (if that field is allocated as a Handle).  Thus, Tim and 
>everybody else who said this are correct.  This is the best way to avoid
>locking handles.

Groan!  Why on earth should one want to copy the _Handle_ itself?

I must not have made myself clear: what needs copying is not the 4
byte Handle, but the *contents* of the block.  That's the stuff that
can move.

But I admit that Tim's example was unfortunate, as it involves two
Handles: wombat, that needs locking, and h, the 4 byte value of which
needs copying because HewHandle() moves memory.

>>It seems better to lock a handle to access big fields.
>>
>
>Bogus conclusion.

Please read more carefully.


>3.  Allocate memory that is never going to be relocated as a pointer.  For
>example, allocate lots of WindowRecords and GrafPorts early in a program
>as a single NewPtr call.  This will keep the heap clean, and you don't have
>to worry about Handle states, and your code will be faster.

What you're telling me is that the safe way to use Handles is to use
Pointers instead.

This far from covers all needs.  All depends on the order in which you
allocate and release memory.  Schematically:

- if you need memory throughout the program, you can use global space
(though you might not want to, for other reasons),

- if memory allocated in a routine is allways released on exit (meaning
that memory is released in strictly the inverse order 


- if