Re: Who is releasing my CFAllocator?
Re: Who is releasing my CFAllocator?
- Subject: Re: Who is releasing my CFAllocator?
- From: Chris Kane <email@hidden>
- Date: Sat, 3 Aug 2002 19:08:19 -0700
On Saturday, August 3, 2002, at 04:42 PM, Nat! wrote:
Am Sonntag den, 4. August 2002, um 01:20, schrieb Ali Ozer:
turns out I am confused by the documentation. The example says:
static CFAllocatorRef myAllocator(void) {
static CFAllocatorRef allocator = NULL;
if (!allocator) {
CFAllocatorContext context = {0, NULL, NULL, (void *)free,
NULL, myAlloc, myRealloc, myDealloc, NULL};
[...]
Why would (void *) free be a suitable value for the release pointer
( CFRelease( CFRetain( myAllocator()))...) ?
The info field points to whatever you want; it's there for your custom
allocator to do its job. The retain and release functions (3rd and 4th
fields in the context) apply to the info field. In the above case, the
info field is a malloc'ed block; the retain func is set to nothing,
and the release func is set to free(), to free the block when the
allocator goes away. I think calling these retain/release is part of
the confusion...
Yeah probably - I am still confused on this part. So release is
actually rather dealloc then ? But what is retain then for, who calls
it when ? Under what circumstances does setting the retain function to
something non-NULL make sense ? Maybe this will lift the fog :)
Your instincts here are quite correct -- free() is a very poor choice
for the release callback, and given that, a real retain function is
probably required too.
Using NULL+free() will work only so long as the CFAllocator retains and
releases the context.info pointer exactly once. Any more (or less! --
probably will never happen) and the app will probably crash. But that's
a detail of the implementation, which wise programmers try not to depend
on.
I can think of examples during the development of the CF implementation
over the last couple years where originally a CF type only retained the
info pointer in a context once, and released once, but later we added
additional retains/releases around certain things going on or for
various reasons. At that point, this example will be in trouble. [If
the app doing such a thing were important enough AND we decided that the
backwards compatibility were important enough, we might put in an
app-specific workaround, the checks for which still slow everybody else
down, or we might detect the simple free() and choose not to ever call
the release function and leak instead.]
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.