Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Graham Cox <email@hidden>
- Date: Tue, 19 May 2015 10:27:55 +1000
I don’t wish to butt in, since you seem to be doing fine and I probably don’t have too much to contribute, but just pointing you at NSDiscardableContent for a second, that has a “pseudo-retain count” type of mechanism that is independent of the actual retain count.
I wonder if that couldn’t help you here - leave the standard retain count to its own devices, and use the access count of NSDiscardableContent to manage your object in these higher-level terms. It requires a little bit of cooperation from all other code that will access your objects, but it makes it a lot saner than trying to reason about retain counts themselves (which I agree with is the path to madness). Since nothing else will be manipulating the access count other than code you write, you can reason about that all day long.
—Graham
> On 19 May 2015, at 10:14 am, Quincey Morris <email@hidden> wrote:
>
> On May 18, 2015, at 16:25 , Britt Durbrow <email@hidden> wrote:
>>
>> If some objects are in autorelease pools, that means that there is a strong link to them out there somewhere (presumably on the stack or in a register where it’s going to go away once the stack frames get popped) and the object pool controller shouldn’t let go of the object yet. Hopefully there will be enough else that can be released that the memory pressure gets satisfied. Also, I can set a flag to cause the object pool controller to re-scan the pool for objects to release after the main autorelease pool is drained in the main event loop.
>
> But here we go, reasoning about retain counts — incorrectly. (Your first sentence is just false, BTW, not incorrectly reasoned. An object can be in an autorelease pool with no other strong link anywhere.) And you’ve got me doing it too. What I said previously about retain counts of objects in autorelease pools was just wrong.
>
>> why I can’t have the object pool controller just drop an object unless the pool controller is the only one with a strong link to the object.
>
> Because what you really want is “unless the pool controller is the only one with an accessible link to the object”. You’re trying hard to force “strong link” to do the duty of “accessible link”, and I’m trying hard to tell you that it can’t.
>
> Also, I’m not trying to steer you towards the double pointer approach. Paradoxical as it may seem, I’m suggesting you can avoid that by merely incrementing the retain count of objects you *know* to be accessible, and to decrement it when you *know* they become inaccessible. You can reason about *that* retain count (“it keeps objects alive when present”). You just can’t validly reason about anyone else’s retain counts. :)
_______________________________________________
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