Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock
Message-ID: <5896@internal.Apple.COM>
Date: 20 Dec 89 18:00:06 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 51
References:<1989Dec19.091303.13316@agate.berkeley.edu> <3373@hub.UUCP>

In article <3373@hub.UUCP> 6600pete@hub.UUCP writes:
> From article <1989Dec19.091303.13316@agate.berkeley.edu>, by 
lippin@skippy.berkeley.edu (The Apathist):
> >>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.
> 
> > Seriously, if this were DTS's position...
> 
> I've seen it twice now posted by DTS employees with no disclaimers
> attached. With explicit declarations that it was official dogma,
> no less. (No, I don't log these things to disk.)
> 
> I know it sounds ugly, but that's what's been said.
> 
> Perhaps it IS the case that one should never write into an unlocked
> hanlde by any means. (Note: I said PERHAPS.)
> 
> Additional input from DTS would be helpful, I'm sure.

Then again, maybe not...

To the best of my knowledge, DTS hasn't formed an official position with 
locking and unlocking handles other than that you definitely need to do it 
if the trap(s) involved might shuffle memory around.

We DO tend to tell people that with all the evil patches running around 
out there that you can't possibly know a priori whether a trap might move 
memory or not, so just code defensively.  Assume the worst.  That sort of 
thing.  It's more a "you might wanna consider this" than a "don't do it."

As has been pointed out in earlier posts, using a debugger with a heap 
scramble option can be very helpful.  Generally speaking, a heap scramble 
function will ALWAYS shuffle the heap anytime that the heap COULD BE 
shuffled.  The definition of this phrase is implementation-dependent; in 
TMON's case, it means whenever the handful of traps that could move memory 
are called either directly or indirectly.

Another good thing to do is to have some utility (a debugger or an INIT) 
that stuffs address zero with some magical longword that's guaranteed to 
cause a Bus Error if accessed on any machine.  It's useful for tracking 
down those intermitent NIL-handle/pointer references.

__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________