rcm@Apple.COM (Robert Monsen) (09/22/90)
In article <16451@unix.SRI.COM> mxmora@unix.UUCP (Matt Mora) writes: [...] >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. Do it with all your handles. If you call a routine, it shouldn't have to know whether the caller has locked it. This can be the source of quite subtle bugs. Believe me, I've been burned by it more than once; because of that, I always use the following: /* File Lock.c */ typedef SignedByte HState; HState MyHLock(Handle h) { HState state = HGetState(h); HLock(h); return state; } void MyHUnlock(Handle h, HState state) { HSetState(h, state); } Lock the handles only when you are using them, and keep the state on the stack in an automatic variable. Believe me, you will be happier if you do. Bob Monsen Orion Network Systems Berkeley Ca.
zellers@prisoner.Eng.Sun.COM (Steve Zellers) (09/22/90)
In article <10360@goofy.Apple.COM> rcm@Apple.COM (Robert Monsen) writes: >Do it with all your handles. If you call a routine, it shouldn't have to >know whether the caller has locked it. This can be the source of >quite subtle bugs. This isn't quite as bad as clearing 0.l so that your code doesn't crash when you derefence nil, but it's almost as bad... 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. 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... -- ------------------------------------------------------------------------ Steve Zellers zellers@prisoner.sun.com "And she wonders if the lizard likes its lettuce rare." -- The Residents
casseres@apple.com (David Casseres) (09/24/90)
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!