On Feb 19, 2009, at 6:26 PM, Dave DeLong wrote:
We've got an app that splits off two threads: one to play some
background music, and the other to count the beats that have passed
so far. We're doing beat counting with a timer (we know the bpm of
the music), but we've got a problem:
We split off a thread to have the beat timer (so it doesn't
interfere with interface responsiveness)
The timer itself wouldn't interfere with interface responsiveness,
even it were on the main thread. Although, the method the timer
invokes may be time-consuming, in which case that would be the
appropriate thing to do.
but we can't figure out how to keep the thread alive and open so
that the timer can fire. At first, the thread would die right after
scheduling the timer on the thread's runloop.
Right. A run loop exits if it has no proper run loop sources. A
timer is not sufficient. So, one strategy is to add a bogus input
source. Creating an instance of NSPort and adding it to the run loop
is the typical solution.
Then we created an NSCondition that doesn't get satisfied until the
music has ended, and then had the counting thread -wait on the
condition.
Our counting thread is now staying alive, but the timer never
fires. Does waiting on the condition lock the thread?
Yes. Timers operate through the run loop. The run loop has to be
running in order for them to fire. A timer can not "interrupt" other
code that's executing. Since you are blocked waiting on a condition,
and since conditions do not use the run loop to do their waiting
(unlike, for example, -[NSTask waitUntilExit]), then the timer can't
fire.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
