Re: CFBridgingRetain does not leak memory
Re: CFBridgingRetain does not leak memory
- Subject: Re: CFBridgingRetain does not leak memory
- From: Ken Thomases <email@hidden>
- Date: Fri, 15 Apr 2016 04:57:16 -0500
On Apr 15, 2016, at 4:34 AM, Tamas Nagy <email@hidden> wrote:
>
> I have an ongoing project where I’m using a CFMessagePort some sort of IPC communication. The CFMessagePort has a callback, something like this:
>
> static CFDataRef Callback(CFMessagePortRef port,
> SInt32 messageID,
> CFDataRef data,
> void *info)
> {
> return CFBridgingRetain([NSArchiver archivedDataWithRootObject:[(__bridge AppDelegate *)info getParameters]]);
> }
>
> The Callback runs on the main queue, it has been setup with CFMessagePortSetDispatchQueue(localPort, dispatch_get_main_queue());
>
> The interesting part is, and I don’t know why is this happening, CFBridgingRetain does not leak memory here - checked out with Instruments, also let the app run for a couple of hours, and memory usage does not increased (check out in Activity Monitor). Should not that CFBridgingRetain leak memory in this example, since I’m retaining a CF object and not releasing it by CFRelease?
No, there's no leak.
Traditionally, memory management in Core Foundation does not use an autorelease mechanism. (There is now a CFAutorelease() function, but that doesn't play into the Core Foundation memory management conventions.) So, if a function needs to return a new or otherwise untracked object, what are its options? It can't release it before it returns it. It may not get an opportunity to release it "some time later". It has to return ownership to the caller.
The caller of your callback is expecting to receiving ownership and takes responsibility for releasing the object it receives. In fact, the documentation for CFMessagePortCallBack says, "The system releases the returned CFData object."
<https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFMessagePortRef/#//apple_ref/c/tdef/CFMessagePortCallBack>
So, your code is doing the right thing.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden