Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Britt Durbrow <email@hidden>
- Date: Wed, 20 May 2015 17:38:18 -0700
>
> On May 20, 2015, at 10:32 AM, Quincey Morris <email@hidden> wrote:
>
> Turns out they weren’t so much off track as you need a smack upside the head. [Er, wait, you’re a big dude with a beard, so perhaps kittens instead? You like kittens? I don’t want to get hurt.]
>
Um… no; that was an example of what *NOT* to do. It was supposed to show what *won’t* work, and what I mean by “loss of graph coherency".
Sorry if that wasn’t clear… We are, in fact, on the same page at this point! :-)
> ** In practice there may be a little something more in the way of housekeeping. If you’re selectively releasing things from the cache, you might need to keep track of what you did, so that you re-retain the correct subset of OPC references later. If you don’t need to be selective, it’s easier because you just release everything in OPC at the start of the memory event, and re-retain everything in OPC [that still has a non-nil pointer in OPC] at the end.
The document objects in question happen to have a flags field in their base class with some unused bits that I’m going to dedicate to tracking that state.
*******************************************************************************************************************************************************
>
> On May 20, 2015, at 9:09 AM, Charles Srstka <email@hidden> wrote:
> The flaw in this example is that VC1 continuing to use DMO1 even after it has told OPC that it’s done with it is a programmer error.
It would be if the system was using something akin to NSDiscardableContent… but remember, there is a body of legacy code that I am trying to disturb as little as possible by making the memory management as automatic as possible.
Also, generally speaking, I don’t want to have to go back to a manual retain/release model for the whole app (which is basically what using NSDiscardableContent entails; even though it isn’t literal -retain and -release calls; the pitfalls are similar).
*******************************************************************************************************************************************************
> On May 20, 2015, at 5:45 AM, Roland King <email@hidden> wrote:
>
> 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)
>
<snip>
Basically, yes. There’s some implementation details involved, but that’s a pretty good summary of the problem… and after doing some more testing, I *think* I have an approach now that will work well enough (some of my initial intuitive concerns didn’t pan out - figures, premature optimization being the hazard that it is; and other things are worse than I thought they were such that the additional overhead of implementing weak links isn’t as high as I thought it would be; and then there’s the explicit retain/release step that Quincey suggested that cuts out having to have two separate containers for the object pool).
_______________________________________________
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