Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Britt Durbrow <email@hidden>
- Date: Sun, 17 May 2015 23:59:22 -0700
Unfortunately I don’t think NSCache will work for me in this situation.
The objects in the pool have a UUID that is used to maintain the graph structure’s coherency when it’s partially or entirely on disk. In RAM, there can be only one object per UUID; but if something points to an object that the cache is trying to evict, that object won’t get deallocated from RAM (because it’s retain count isn’t zero post eviction) but the object pool controller won’t know about it still being in RAM (as it’s no longer in the cache), and when the controller attempts to reload it from disk; there would be multiple in-memory objects purporting to have the same UUID. As is oft claimed about these sorts of situations, hilarity would ensue…
Keeping multiple pointers to the same object strikes be as ugly also… perhaps more ugly than just looking at retainCount: it does more or less the same thing, but with a greater footprint (memory, CPU, and battery).
My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. However, it’s not actually something that’s likely to get deprecated; and by paying very careful attention to the rules, it should be OK to use in this very narrow circumstance?
If this is wrong - please (hopefully someone from Apple) correct me!
:-)
_______________________________________________
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