Re: Converting from Carbon Event Manager to NSTimer
Re: Converting from Carbon Event Manager to NSTimer
- Subject: Re: Converting from Carbon Event Manager to NSTimer
- From: Dan Birns <email@hidden>
- Date: Wed, 24 Sep 2008 16:18:56 -0700
I have my problem largely resolved, and I thought I'd share the
resolution.
Some have written pointing out that the following code has a bug:
timer = [NSTimer alloc];
[timer initWithFireDate:[NSDate date] interval:t target:self
selector:@selector(mainLoopTimer:) userInfo:halTimer repeats:NO];
timer may be set to the wrong thing because I don't reset it to what
init returns, which can change its value. This was probably my
problem. However, my resolution was unrelated to this.
Our API with timers assumed that it was only setting the 'next' timer,
not 'yet another' timer. The business of handling multiple timers is
done internally in our portable code.
So what happened when I used [NSTimer
scheduledTimerWithTimeInterval... I was getting another timer. The
result was that my selector would get called maybe 10X more often than
intended. This didn't break anything, but impaired performance. So
now I simply add a call to [timer invalidate]; before adding a new
timer. It's true that we're allocating a new timer with every call,
and I'd prefer not to do that, but this seems to be working okay for
now.
I may go back and try to use initWithFireDate: later...
I must say, after 20 years of C malloc(), I find retain/release
mysterious. It's probably no better or worse than malloc/free, but
confusing to me. It seems to me that it has exactly the same
advantages/disadvantages, but it's just wildly different. Who does
the free()? Who does the retain/release? Pretty much the same
problem...
--Daniel
I'm trying to convert from Carbon to Cocoa for a number of reasons
which I won't go into here.
My application needs to set a timer that causes a function to be
called at a time in the future. This is non-repeating, and
sometimes has be immediate. I need it to be as efficient as
possible, because it's called frequently.
In Carbon I'm using:
EventLoopTimerUPP upp;
upp = NewEventLoopTimerUPP(macTimerCallback);
InstallEventLoopTimer(GetMainEventLoop(),0, kEventDurationForever,
upp,0,&macTimer);
Then, when I need to set the timer:
nextTimerTime = CFAbsoluteTimeGetCurrent() + nextTimer;
SetEventLoopTimerNextFireTime(macTimer, nextTimer);
In Cocoa, the system I'm using requires me to allocate a new NSTimer
every time I need to set a timer:
self.timer = [NSTimer scheduledTimerWithTimeInterval: t // seconds
target: self
selector: @selector (mainLoopTimer:)
userInfo: nil
repeats: NO];
This is working fine, but our performance is poor. It's not so poor
that it's obviously broken, but I'm looking for ways to improve it.
I've been try to alloc one NSTimer that I reuse, and I've had no
success doing so.
I've tried
timer = [NSTimer alloc];
[timer initWithFireDate:[NSDate date] interval:t target:self
selector:@selector(mainLoopTimer:) userInfo:halTimer repeats:NO];
[[NSRunLoop currentRunLoop] addTimer:timer
forMode:NSDefaultRunLoopMode];
This has failed. Investigating, I called [timer isValid] and it
returns false. I've tried altering the args in various ways without
success. I've also had various problems retain'ing this timer.
When I add [timer retain];, it crashes having exhausted the stack,
where it's calling retain over and over.
Help.
--Daniel
_______________________________________________
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