mikeash.com pyblog/friday-qa-2010-04-30-dealing-with-retain-cycles.html comments

Sayeed Munawar Hussain - 2014-10-30 04:45:45

Thu, 30 Oct 2014 04:45:45 GMT

Great post Mike. Thanks for creating Friday QA. Learned a lot here.

bob - 2012-12-14 23:55:37

Fri, 14 Dec 2012 23:55:37 GMT

About the NSTimer and retain cycles, this only applies to timers with repeat:YES, right? Because if it does not repeat, it will invalidate itself after firing, at which point it will release its target, so it is not a permanent retain cycle.

Omar - 2012-11-02 19:34:38

Fri, 02 Nov 2012 19:34:38 GMT

I understand, thanks.

mikeash - 2012-11-02 15:03:32

Fri, 02 Nov 2012 15:03:32 GMT

NSThread will retain the target for as long as the thread is alive. If you're terminating the thread before your object is supposed to be deallocated, you're fine. If you're telling the thread to exit in -dealloc, then you'll never get there.

All Cocoa APIs need a periodic autorelease pool drain to clean up their stuff. If you're running your own long-lived thread, then you need an autorelease pool in your thread's top-level loop.

Omar - 2012-10-29 04:41:14

Mon, 29 Oct 2012 04:41:14 GMT

What about NSThread?
For example, if I have, in a viewDidLoad:
myThread = [NSThread detachNewThreadSelector: @selector(go) toTarge:self withObject:nil];

And then I have
- (void) go
{
  //do something
}

There is no cycle here, correct? When the go function ends, so does the Thread... or not?

What if the go function were something like this:

- (void) go
{
  while (![NSThread isCancelled])
  {
    //alloc something
    NSData *d = [NSData dataWithContentsOfFile: @"somefilepath"];
    [NSThread sleepForTimeInterval:1];
  }
}

I found out, in this case, that "d" is never deallocated, until the thread exits.
It seems that an @autoreleasepool{} is needed around the NSData allocation, for it to be properly released after each cycle. Is that correct?

But still, if I have for example:

- (IBAction) goBack
{
  [myThread cancel];
  myThread = nil;
  [self.navigationController popViewControllerAnimated:YES];
}

This will still clear the thread, and the viewController itself, and all the NSData that were allocated, right?

Anything else I should be aware when doing things like these?

Thanks a lot for your very informative posts.

mikeash - 2010-05-29 23:04:02

Sat, 29 May 2010 23:04:02 GMT

Using a setter to set to nil is just a convenient way to release the variable. For more information on this technique and the pros and cons of it, see this post:

http://www.mikeash.com/pyblog/friday-qa-2009-11-27-using-accessors-in-init-and-dealloc.html

Keith Selbee - 2010-05-29 10:46:21

Sat, 29 May 2010 10:46:21 GMT

In your first code example above, why are you setting _b's A ref to nil? If this is the B dealloc there's no chance it's going to call A later, right?

mikeash - 2010-05-04 21:09:28

Tue, 04 May 2010 21:09:28 GMT

jt: And thanks very much for saying so, always nice to see.

jt - 2010-05-01 20:35:03

Sat, 01 May 2010 20:35:03 GMT

Mike: Just wanted to say how much I appreciate the Friday sessions. Thanks.

James Walker - 2010-05-01 07:18:44

Sat, 01 May 2010 07:18:44 GMT

Jeff, what's the advantage of using a notification, rather than having the target object have a nonretained pointer to the owner object, and sending it a message directly when the timer fires?

Anonymous - 2010-04-30 19:28:26

Fri, 30 Apr 2010 19:28:26 GMT

Jeff, that's a really cool solution. Essentially you're adding an intermediary object (NSNotificationCenter) between the two objects involved, which breaks the retain-cycle by referring to your target via simple pointer assignment. Very clever!

Jeff Johnson - 2010-04-30 17:30:59

Fri, 30 Apr 2010 17:30:59 GMT

I like to avoid timer retain cycles by creating a special timer target class that posts a notification when the timer fires. The owner of the timer observes the timer target notification. The timer retains the special target class rather than the owner of the timer, so there's no retain cycle.

Alex Blewitt - 2010-04-30 17:25:02

Fri, 30 Apr 2010 17:25:02 GMT

Did you meain 'retaining' cycles for the subject of the post? There's a missing 'in' somewhere, I think

cygnl7 - 2010-04-30 16:54:55

Fri, 30 Apr 2010 16:54:55 GMT

Never mind. I had the ownership backwards.

cygnl7 - 2010-04-30 16:53:26

Fri, 30 Apr 2010 16:53:26 GMT

In the fixed NSTimer example, self is still the parameter to target. Doesn't that still create a retain cycle? Shouldn't the target be the new child Impl class?