Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!apple.com!casseres
From: casseres@apple.com (David Casseres)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Handles (was Re: HLock interdiction??)
Message-ID: <10377@goofy.Apple.COM>
Date: 24 Sep 90 16:51:07 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 35
References:<1990Sep21.043054.24649@cunixf.cc.columbia.edu> <16451@unix.SRI.COM> <10360@goofy.Apple.COM> <142885@sun.Eng.Sun.COM>

In article <142885@sun.Eng.Sun.COM> zellers@prisoner.Eng.Sun.COM (Steve 
Zellers) writes:
> Do things because
> you understand them, not because you've been burned by them.  IM would
> let you know if a handle will be locked/unlocked/disposed of by a
> routine.  Don't do it unless you have to.

Well, I hope I don't offend anyone by saying this but I do not fully trust 
IM or future versions of the System on this score.  IM is normally at 
least a little bit out of date, it doesn't tell me what traps are called 
by "glue" calls, there's always the chance that some ROM routine that 
does not scramble the heap today will be forced to do so tomorrow, and I 
can't be sure what the compiler is going to do with certain code 
constructs.  My rule is: *When in doubt*, lock handles.

> In your own code, pay attention to who may lock a handle, and write
> your routines in a manner to reduce handle locking.  They don't cost
> that much now, but who knows what will happen in the future?
>
> I'd much rather have fast, well written software, than slow, well written
> software...

I've never heard of a piece of code that was slowed appreciably by HLock 
and HUnlock calls.  As for the future, even a paranoid like me can 
comfortably assume that the System guys are not going to suddenly make it 
expensive to lock handles on the Mac!

But you're right to the extent that it makes sense to lock a handle just 
before a tight loop and unlock it afterward, rather than lock/unlock it 
inside the tight loop.  And the thing that will screw up your memory 
management, of course, is to keep something locked a lot longer than it 
needs to be; this is a fairly common error.

David Casseres
     Exclaimer:  Hey!