Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HUnlock always after HLock?

On 11/2/03 2:54 PM, Dan Crevier wrote:
> On 11/1/03 9:00 AM, "Steve Zellers" <email@hidden> wrote:
>> But don't bother using HLock/HUnlock or HSetState on Mac OS X. (Unless
>> you know that someone is going to explicitly look at those bits.) The
>> handle will not move or be purged on OS X.
>
> Is this behavior guaranteed for the future? Is it documented anywhere?

http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemo
ry/Tasks/MemoryAlloc.html

> If you have code that makes calls to HLock, HUnlock. HSetState, or HGetState,
> you can either conditionally compile that code out for Mac OS X or you can
> remove the code entirely. The only exception to this rule is cases where your
> code calls the SetHandleSize function, which can potentially move a handle if
> more space is required. If your code needs to access a handle that might be
> resized at some point, you should lock the handle first.

That seems pretty clear, except there's a gotcha about locking a block that
might be resized.

http://developer.apple.com/documentation/Carbon/Reference/Memory_Manager/mem
ory_mgr_ref/function_group_5.html#//apple_ref/c/func/SetHandleSize

> SetHandleSize might need to move the relocatable block to obtain enough space
> for the resized block. Thus, for best results you should unlock a block before
> resizing it.

You probably are best off minimizing the use of handles to where they are
required by the API. If there is any chance your code may find its way to
Carbon/Mac OS 9, you still need to be careful about handles moving.

Please note it really isn't necessary to lock handles that often. Use robust
coding techniques that work even if the handle moves. For example, instead
of:

Ptr p = *h;
c = *p++;

use:

long i = 0;
c = (*h)[i++];

If you really, really want to use pointers, you can reevaluate them after
calls that may move memory. For example:

DoSomethingWith(h); // may invalidate p
p = *h + i; // recompute p

The cost of reevaluating a pointer is much less than calling HGetState,
HLock, and HSetState, and it doesn't clog up the heap with locked blocks.

The one case where you must lock a handle is when calling a function that
takes a pointer, because it may make calls that move memory and it will not
know the pointer could be affected. The even better solution is to rewrite
the calling code to use an ordinary heap block instead of a handle.

Regards,

Tom

--
Tom Becker "Sometimes, it's the things you don't see
<email@hidden> that have the biggest impact."
-- From an ad by Enron Corporation
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: HUnlock always after HLock? (From: Dan Crevier <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.