Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!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: <3899@atr-la.atr.co.jp>
Date: 28 Dec 89 12:13:21 GMT
References: <3875@atr-la.atr.co.jp> <4525@helios.ee.lbl.gov> <3888@atr-la.atr.co.jp> <9419@hoptoad.uucp>
Organization: ATR International,Japan
Lines: 92
In-reply-to: tim@hoptoad.uucp's message of 27 Dec 89 22:38:18 GMT


>>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.
>
>You still haven't made yourself clear; I really haven't the faintest idea
>what you're talking about.  Could you provide a code example?

OK, here's a piece of code:

	/* saveBits is a Handle containing a BitMap record
	  followed by the bit image data.  It needs locking
	  because CopyBits can move memory. */

	state = HGetState((Handle) saveBits);

	HLock((Handle) saveBits);
	fixBitMap(saveBits); /* the baseAddr field is incorrect if the 
				block has moved, fixBitMap() corrects it */

	CopyBits(&(w->portBits),*saveBits,
		&(w->portRect),&(**saveBits).bounds,srcCopy,NULL);

	HSetState((Handle) saveBits, state);	/* restore state */

The "contents of the block" in the quotation above would refer here to
the BitMap record and its associated bit image data.  Using the "copy
to temp" method to avoid locking would require a big piece of stack or
non-relocatable heap, time to copy, and the faith that whatever you
use to copy won't scramble the heap.  BlockMove() is said to be safe,
but I'm less sure about calling strcpy() on a string in a Handle.

I'm not saying one shouldn't copy to temps, even in this case.  Maybe
it's the cleanest way.  I don't know.  I'm here to learn.

The reason for putting the offscreen bitmaps in Handles is that they
are allocated and released as the user creates and disposes windows.
As the user is expected to use many windows (up to say, 50 in a
session), using Pointers instead would badly fragment the heap.  I'm
less worried about WindowPtrs because they are all the same size, and
I expect new ones to tend to occupy the slots left by old ones.


>>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.
[...]
>And after reading the above quoted paragraph five times, I have to
>wonder if *you* know what you mean.  wombat does not require locking.
>You can't lock a structure field; that makes no sense.  h does not
>"require copying because NewHandle moves memory"; I don't even know
>what that is supposed to mean.  It is there because the statement
>
>(*marsup)->wombat = NewHandle(WOMBAT_SIZE);
>
>may be evaluated left to right.  First, the address of

Mea culpa. I mistyped wombat for marsup.  The posting escaped me
before I could check.  The phrasing wasn't too good either.  It's
indeed not _wombat_ that might need locking, but _marsup_.  It should
make sense this way:

"Tim's example was unfortunate because it involves two Handles: one
whose fields might move in memory (marsup), and another returned by
NewHandle().  The latter is the example of a 4 byte value that is
copied to temp h, to avoid having to lock marsup."

A different choice for that value (say, a Pointer returned by
NewPtr()) would have made the example clearer.

>>>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.
>
>No he isn't.  WindowRecords and GrafPorts *have* to be pointers in the
>Mac OS.

I *know* that.  Presenting as a choice something the OS enforces
anyway wouldn't make sense anyhow.  Recall that the discussion is
about Handles.  I interpret Patrick's point as saying one should plan
out memory needs as far as possible, and allocate memory early, in
non-relocatable blocks.  Good point, but not relevant to Handle
locking in cases where Handles are called for.

Anyhow, my apologies again for posting a badly written article.

Alain de Cheveigne,
alain@atr-la.atr.co.jp