Re: NSTimer memory management

On Sun, Sep 26, 2010 at 5:39 PM, Jeff Johnson wrote: > On Sep 23, 2010, at 6:13 PM, slasktrattena...@gmail.com wrote: > >> In this particular case, though, I might just as well get rid of the >> timer altogether and go for NSObject's >> performSelector:afterDelay:/cancelSelector: instead. Jeff's >

Re: NSTimer memory management

On Sep 23, 2010, at 6:13 PM, slasktrattena...@gmail.com wrote: > In this particular case, though, I might just as well get rid of the > timer altogether and go for NSObject's > performSelector:afterDelay:/cancelSelector: instead. Jeff's > enlightening (and frightening!) discussion about implicit r

Re: NSTimer memory management

On Sep 24, 2010, at 5:06 AM, Andreas Grosam wrote: > On Sep 23, 2010, at 3:50 AM, Jeff Johnson wrote: > >> Your object retains the timer, and the timer retains your object. That is >> obviously a kind of retain cycle. > I think, this kind of retain cycle is not a problem by itself when a > repe

Re: NSTimer memory management

On Sep 23, 2010, at 3:50 AM, Jeff Johnson wrote: > Your object retains the timer, and the timer retains your object. That is > obviously a kind of retain cycle. I think, this kind of retain cycle is not a problem by itself when a repeating timer is used. > What can happen is that your app gets

Re: NSTimer memory management

Thanks all for the input. I'll take Scott's and Gregory's advice to not retain the timer. I've seen this advocated before, but always felt uneasy about not retaining my pointers. It just goes against all I ever learned about Cocoa. In this particular case, though, I might just as well get rid of t

Re: NSTimer memory management

slasktrattena...@gmail.com wrote: > Is this an over-release? > > timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; > ... > [timer invalidate]; > [timer release]; Seems fine, although based on

Re: NSTimer memory management

On Sep 22, 2010, at 7:50 PM, Jeff Johnson wrote: > The NSTimer API is somewhat unfortunate. It would probably be better to have > a delegate API where the delegate is not retained. However, that ship has > sailed. What you need to do is avoid the retain cycle. What I sometimes do is > to create

Re: NSTimer memory management

It might be informative to see the entire backtrace and/or the entire source for the class, but in any case, I believe that the issue is "target:self". According to the NSTimer documentation, "The target object is retained by the timer and released when the timer is invalidated." Your object re

Re: NSTimer memory management

> Is this an over-release? > > timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; > ... > [timer invalidate]; > [timer release]; No, you're not over-releasing the timer. > I've seen this pattern so many times I figured it was correct, > although it doesn't seem to comply with the me

Re: NSTimer memory management

- (void)invalidate Discussion This is the only way to remove a timer from an NSRunLoop object. The NSRunLoop object removes and releases the timer, either just before the invalidate method returns or at some later point. On Sep 22, 2010, at 5:38 PM, slasktrattena...@gmail.com wrote: Hi

NSTimer memory management

Hi, Is this an over-release? timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; ... [timer invalidate]; [timer release]; I've seen this pattern so many times I figured it was correct, although it doesn't seem to comply with the memory management rules (i. e. the timer is first impl