• 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: Overriding -release to break retain cycle. Was: Doc for -release not quite true
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overriding -release to break retain cycle. Was: Doc for -release not quite true


  • Subject: Re: Overriding -release to break retain cycle. Was: Doc for -release not quite true
  • From: Michael Ash <email@hidden>
  • Date: Sun, 29 Aug 2010 20:29:15 -0400

On Sun, Aug 29, 2010 at 5:58 PM, Jerry Krinock <email@hidden> wrote:
>
> On 2010 Aug 23, at 19:02, Daniel DeCovnick wrote:
>
>> But it doesn't really matter since you should never be calling dealloc except from release or dealloc (as [super dealloc];) anyway.
>
> No, I haven't called -dealloc for quite a few years  :)
>
> Actually, I was studying Uli Kusterer's old UKKQueue.  One of his instances detaches a secondary thread with the instance itself as target, creating a kind of retain cycle:  The secondary thread won't exit until the instance is deallocced, and the instance won't be deallocced until the secondary thread exits.  To fix this, he overrode -release, and messages (via ivar) the secondary thread to exit when the pre-release retainCount == 2.  I believe it is a pretty neat trick, but couldn't understand it until I corrected Apple's documentation of -release.

A side note: while this is an interesting and somewhat useful
technique for breaking retain cycles, it's also fragile. The problem
arises if two different pieces of code both apply this technique to
the same object, which in this case could happen if you subclass. In
that case, the retain count reaches 3 at which point the cycles need
to be broken, but since the count never drops to 2, they are not.

Much better is to avoid causing the retain cycle in the first place.
This sort of problem was what prompted me to create MAZeroingWeakRef:

http://www.mikeash.com/pyblog/introducing-mazeroingweakref.html

For this particular case, you could use an instance of
MAZeroingWeakProxy as the thread's target, and set a cleanup block
which tells the thread to exit, or there are a variety of other
possibilities which arise once you have reliable weak references
available.-

For anyone contemplating retain cycles and how to break them, I
strongly encourage you to have a look.

Mike
_______________________________________________

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

References: 
 >Re: Documentation for -release is not quite true (From: "Gary L. Wade" <email@hidden>)
 >Re: Documentation for -release is not quite true (From: Daniel DeCovnick <email@hidden>)
 >Overriding -release to break retain cycle. Was: Doc for -release not quite true (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Overriding -release to break retain cycle. Was: Doc for -release not quite true
  • Next by Date: sdef NSXMLParserErrorDomain error 1549 in 10.5, PowerPC
  • Previous by thread: Overriding -release to break retain cycle. Was: Doc for -release not quite true
  • Next by thread: Re: Documentation for -release is not quite true
  • Index(es):
    • Date
    • Thread