NSTimer possible crash cause - objective-c

Question

I have an issue while working with NSTimer.
Let's assume I have this architecture :
ThreadedClass.m (contains a NSTimer* timer;)
- (id) init {
if (self = [super init]) {
// do blablabla
[self launchAThread];
}
return self;
}
- (void) launchAThread {
[NSThread detachNewThreadSelector:#selector(selectorToMyThreadFunction)
toTarget:self
withObject:nil];
}
- (void) selectorToMyThreadFunction {
//I do my stuff in here
//Then i relaunch a Timer to call this function
//periodically but it has to be "atomic" so no
//repeating timer since i don't know the time
//this function will take
//I do some [self changeSomething];
[self restartTimer];
//MyThread ends here (and might be recreated by the Timer's bip
}
- (void)restartTimer {
if (![NSThread isMainThread]) {
[self performSelectorOnMainThread:#selector(restartTimer)
withObject:nil
waitUntilDone:NO];
return;
}
[timer invalidate];
[timer release];
timer = [[NSTimer scheduledTimerWithTimeInterval:interval
target:self
selector:#selector(launchWithTimer:)
userInfo:nil
repeats:NO] retain];
}
- (void) launchWithTimer:(NSTimer *)theTimer {
if (theTimer == timer)
{
[timer release];
timer = nil;
[self launchAThread];
}
else
{
//Nothing to be done in here, a user launch a thread manually
}
}
So let's assume the user of the class alloc it and release it right after. My timer will still be alive and the object too (since there is a retain made by the timer).
When the timer will fire, it will do [self launchAThread] and then the timer will invalidate and release itself AND it will release my object which now has a retainCount = 0... Let's assume, one more time, the object is deallocted right after, this will cause crash and there is nothing i can do to stop it that comes right to my mind.
I agree, this is a lot of assumptions but i'm curious to know if someone already had this issue and how he solved it.
Thanks for reading and I hope I was clear ! :)

Answer 1

Yo have to always invalidate your timer before releasing it. If the timer is a part of a view controller I am always invalidating it in viewWillDisappear. For me is so odd that NSTimers retains theirs owners. I think the best way is to create - (void)cleanUp method, that will invalidate the timer and warn the user of the class to ALWAYS use cleanUp before releasing. If somebody knows the better way I will be glad.

Answer 2

As long as you're not using a repeating timer, why not use dispatch_after? You'll save yourself the headache and overhead of the NSTimer object. And if you just stick with GCD you can avoid the call to detachNewThreadSelector: as well.

Answer 3

NSRunloop will retain the timer for you, which means you don't have retain/release it at all

Answer 4

Since I'm making a library, i can't assume that the user will call a cleanUp function anytime.
So to solve my problem, I added a new "layer" : a new class that will do the thread and timer part so that I am the user of this class and I know I have to cleanUp !

Answer 5

I first resorted to using a cleanUp kind of function too.
I also have an object A owning object B that contains the timer - which retains object B. When object A is deallocated it releases object B, but B lives on because the timer retained it. Then in the method fired but the timer, I'm using a delegate relationship to call back to object A → hard crash. This is where object A needs to "cleanUp" B's timer. This could lead to other problems though if other objects also rely on object B. And also class A shouldn't and might not know the implementation secrets of class B. :-P I guess a good solution could be to unset that delegate relationship before releasing is done in A's dealloc because you don't know if B will die even if you released it - someone else might have retained it (LIKE THAT D*** NSTIMER)... :-P