> On 20 May 2015, at 1:04 pm, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > I don’t think you’ve misunderstood anything at all.
Kind of you to say so - I’m not so sure :) > > So, we look at two possible solutions. [Spoiler: Both solutions are 100% > correct, because both solutions are 100% identical, as far as memory > management is concerned.] > > Solution A: We create an additional strong reference to each object in the > cache, kept in (say) a Cocoa collection. That allows us to selectively mark > objects purgeable by removing some or all of these strong references. > Drawback: We’re wasting memory for storing the additional strong references. > > Solution B: We retain each object as it enters the cache. That allows us to > selectively mark objects purgeable by releasing them again. Drawbacks: None. > > The end. > I think what the OP says he wants is that the cache can only release when it knows nobody else has a reference to an object as well, hence the temptation to peek at the retain count. In other words it must be the “last owner”, for some reason. The cache may have good reasons for requiring that it be the “last owner” of a cached object, but that seems orthogonal to retain/release. If the argument is that the cache assigns the UUIDs to the objects so it must be the “last owner” in order that these be unique, I think that’s possibly where the reasoning is flawed. A UUID is unique by definition, isn’t it? So there’s no need to do extra work to ensure uniqueness. Or it may have other reasons altogether, and the reasoning might not be flawed. It’s in that case that NSDicardableContent (or something akin to it) might be useful, because it provides something that looks like retain/release in principle but is outside of, and unaffected by it. It would allow the cache to know when any object it owns is not being accessed, even if that object were, from a memory management point of view, owned by something else as well. This is where using retain/release is bad, because an object can’t know if it’s the “last owner” without peeking, and as we know as peeking isn’t reliable, we have to rule it out. There are different ways to solve this - for example, maybe the cache provides an interface for vending and devending objects that it knows about such that it will only discard unvended objects, but in effect, that’s identical to the NSDiscardableContent pattern, just centralised awkwardly. I think the solution to this must come from a really good explanation from the OP as to why the cache MUST be the “last owner”. It’s that requirement that is forcing the issue, but it’s not that clear why that is a requirement. —Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
