On Thu, Feb 19, 2009 at 7:42 PM, Ken Thomases <k...@codeweavers.com> wrote: >> 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.
You're probably going to want to do this anyway so you can signal the thread to cancel or other such things. You can do this with shared memory, of course, but then you'll have to rely on the timer pulse to check it... Speaking of which, timers are not guaranteed to fire at regular intervals, and if a pulse is skipped (for example, doing long processing in another input source) that pulse is dropped. Have you considered the implications of this behavior? I have to do something related in an app I'm developing, and I'm using Core Audio. I'm going to hook a render notification callback up to the output unit and have that post notifications to my UI thread. You might want to use the same approach for your beat analyzer. --Kyle Sluder --Kyle Sluder _______________________________________________ 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
