Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!agate!skippy!lippin
From: lippin@skippy.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock
Message-ID: <1989Dec19.091303.13316@agate.berkeley.edu>
Date: 19 Dec 89 09:13:03 GMT
References: <3331@hub.UUCP> <3332@hub.UUCP>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 38

Recently 6600pete@hub.UUCP wrote:
>DTS' official position now is that there are so many patched traps running
>around calling the Memory Manager that you need to lock and unlock handles
>around ANY trap call. The list, in other words, is no longer valid. For
>the record, the following situations involve locked handles:
>
>   passing elements of records pointed to by dereferenced handles as Pascal
>      "var" parameters
>   assigning return values from function-style traps to elements of records
>      pointed to by dereferenced handles
>   inside Pascal "with" statements which include handles in the "with"
>
>Can anyone think of any other situations?

How about: 
    In any piece of code that may be interrupted by some task that
	makes a toolbox call.

Which, of course, is anything that runs without masking out
interrupts.

Seriously, if this were DTS's position, they would be saying that it's
never legal to look into an unlocked handle.  Coding around this would
impose ridiculous penalties on performance.  Luckily, they don't have
to go this far, because we can be sure that interrupt routines don't
move or purge handles.  Why?  Because they don't use traps that are on
the danger list.

On the other hand, they do want to say that nothing is forever -- once
upon a time, SysBeep was a memory-safe trap.  When all else fails,
they just have to rely on your toolbox karma.

					--Tom Lippincott
					  lippin@math.berkeley.edu

"Just a moment... Just a moment... I'm picking up a fault in the AE-35
 subunit.  It will go one hundred percent failure within seventy-two hours."
					--HAL