Re: NSDistributedNotificationCenter questions.
Re: NSDistributedNotificationCenter questions.
- Subject: Re: NSDistributedNotificationCenter questions.
- From: "Mr. Gecko" <email@hidden>
- Date: Fri, 18 Feb 2011 16:19:31 -0600
I know that you think I'm some noob at this. This may be true, but I am aware that Instruments shows that the memory I allocated during that distributed notification is still there. I know this because it's a 9MB allocation and it's in a NSData with no copy bytes and free when released. The one thing I may not understand is when things are released and when they are shown to be released in instruments. I should play around in a test application with allocing things, but from what I can think of it's not being released as it shows it as alive in instruments. The way programming works is there is a run loop in the main of the application and in that run loop they create a autorelease pool, when there is an event, it will call the right object for that event and run the right method for the event, after the event runs, it'll drain the autorelease pool and continue to listen for more events. That's my understanding and I think that when you drain the autorelease it would release ALL objects that was added to it and when the retainCount reaches 0, it'll free it from memory. Now this all makes sense to me, if it doesn't work this way, I don't understand how it works and would appreciate it if someone told me what it actually does.
On Feb 18, 2011, at 4:01 PM, Fritz Anderson wrote:
> You're thrashing around for an explanation for something that I don't think needs explaining.
>
> How do you know "memory is not autoreleased?" What do you mean by that? If it's simply that the retain count isn't what you expect, forget it. Forget retainCount is in the API; if your situation tempts you to look at retainCount, retainCount is almost guaranteed to be misleading. The OS has the right to retain, and later release, any object at any time. So long as you and the OS both obey the memory-management rules (which means, on your part, not sprinkling releases and drains whenever you're in doubt), the object will be deallocated when you and the OS are both done with it.
>
> That Instruments doesn't show "these allocations" (what allocations?) as a leak raises a strong presumption that it isn't a leak. Your attempt to plug a leak that isn't there will crash your application.
>
> You application, the other application, and the OS all have their separate memory spaces and heaps. You (and therefore the retain/release logic for your application) have no access to any heap but your own. It doesn't matter whether the other application has retained its copy (note: copy) of its object. You're looking at your own copy.
>
> — F
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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