Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!prisoner.Eng.Sun.COM!zellers
From: zellers@prisoner.Eng.Sun.COM (Steve Zellers)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock interdiction??
Keywords: MacTutor, Memory Manager, DogCow
Message-ID: <142875@sun.Eng.Sun.COM>
Date: 21 Sep 90 21:45:17 GMT
References: <1990Sep21.043054.24649@cunixf.cc.columbia.edu> <10348@goofy.Apple.COM>
Sender: news@sun.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 23

In article <10348@goofy.Apple.COM> stevec@Apple.COM (Steve Christensen) writes:
>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 
>>whether a handle is locked, and if so... with what mask???
>
>Was this described as a bug or feature?  HLock has always locked a block for
>me, and HUnlock has unlocked it.  It's never toggled the state.

  I've a feeling that this thread was based on the fact that, what with
all the data hiding and class library subclassing going on these days,
a Handle may be passed to a routine that may _or may not_ be locked.
In this case, it is _imperitive_ that you save it's state with HGetState
and smuk it back afterwards with HSetState if you need to ensure that
it's locked.
  If HLock toggled, all hell would break loose...
--
------------------------------------------------------------------------
Steve Zellers 					zellers@prisoner.sun.com
"And she wonders if the lizard likes its lettuce rare." -- The Residents