• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tracking the retain count
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking the retain count


  • Subject: Re: Tracking the retain count
  • From: Quincey Morris <email@hidden>
  • Date: Tue, 19 May 2015 00:14:57 +0000

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


  • Follow-Ups:
    • Re: Tracking the retain count
      • From: Graham Cox <email@hidden>
References: 
 >Tracking the retain count (From: Britt Durbrow <email@hidden>)
 >Re: Tracking the retain count (From: Jonathan Hull <email@hidden>)
 >Re: Tracking the retain count (From: Britt Durbrow <email@hidden>)
 >Re: Tracking the retain count (From: Quincey Morris <email@hidden>)
 >Re: Tracking the retain count (From: Britt Durbrow <email@hidden>)
 >Re: Tracking the retain count (From: Ken Thomases <email@hidden>)
 >Re: Tracking the retain count (From: Britt Durbrow <email@hidden>)

  • Prev by Date: Re: Tracking the retain count
  • Next by Date: Re: Tracking the retain count
  • Previous by thread: Re: Tracking the retain count
  • Next by thread: Re: Tracking the retain count
  • Index(es):
    • Date
    • Thread