Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!wuarchive!husc6!unix!mxmora
From: mxmora@unix.SRI.COM (Matt Mora)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock interdiction??
Keywords: MacTutor, Memory Manager, DogCow
Message-ID: <16451@unix.SRI.COM>
Date: 21 Sep 90 16:09:24 GMT
References: <1990Sep21.043054.24649@cunixf.cc.columbia.edu>
Reply-To: mxmora@unix.UUCP (Matt Mora)
Organization: SRI International, Menlo Park, CA
Lines: 29

In article <1990Sep21.043054.24649@cunixf.cc.columbia.edu> jtt@cunixd.cc.columbia.edu (James T. Tanis) writes:
>while reading the September issue of MacTutor, in the Mousehole echo,
>I saw a disturbing exchange...
>
>the gist was, that HLock would _Unlock_ an object if it was locked to
>begin with. Is this the case? Should I call HGetState first, to determine 

This is not gist of it. You misunderstood what he meant. Hlock does not
toggle the lockedness (is that a word?) of a handle. What he meant was
that something else (maybe a rom routine) might have the handle locked for
a reason. The you come around lock the locked handle (nothing happens because
its already locked) do your thing then unlock it. Blamo, your program dies
a miserable death because the thing that locked it before, now receives an 
unlocked handle, problably moves some memory and then crashes.

You need to use Hgetstate/Hsetstate to keep the handle as it were. If you need
to lock a handle by all means do it. Just save the state of the handle before
hand and reset it back after you are done with it. Remeber that handles can 
have more states than just being locked. Also you probably don't need to do 
this with all handles, just the ones that you share with the ROM.




-- 
___________________________________________________________
Matthew Mora                |   my Mac  Matt_Mora@sri.com
SRI International           |  my unix  mxmora@unix.sri.com
___________________________________________________________