Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Roland King <email@hidden>
- Date: Wed, 20 May 2015 20:45:03 +0800
> On 20 May 2015, at 20:00, Dave <email@hidden> wrote:
>
> I’ve been read this thread with interest, I think you are over-complicating things, unless I missed something.
….
> Isn’t this what you want to achieve?
No that’s not what he wants to achieve. He wants
1) When he needs an object pertaining to a given UUID he wants
1.1) if it doesn’t exist - to create it and keep it mapped to the UUID in some manner such that
1.2) if it does exist he just returns the same object as before.
There can never be two objects living which represent the same thing (ie UUID)
Now that would just be a mutabledictionary, if there was infinite RAM it would be fine, you collect them forever and return them as needed. But RAM is not so he wants to throw the objects away again if no client is still using them and recreate them if needed next time.
That would be a weak map, as the final client releasing the object will cause it both to dealloc (as the map holds it only weakly) and the map would remove the key because weak maps do that.
But that’s still not good-enough. The objects are expensive to create so he doesn’t really want to throw them away when no client is using them, he only wants to throw them away when no client is using them and he gets a memory pressure trigger. That would mean going through the (strong) map evicting objects which have no clients referencing them, but no others, if a client still references the object, it has to stay in the map. To do that you need to know which objects are still ‘in use’. You can’t remove everything from the dictionary, you can only remove things which are not currently referenced by clients. Hence all the talk of inspecting retain counts to figure out if the only thing referencing an object is the dictionary/map it’s in.
Quincey’s redux of the two possibilities earlier well-described two good solutions.
_______________________________________________
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