Re: Running a timer on a separate thread
Re: Running a timer on a separate thread
- Subject: Re: Running a timer on a separate thread
- From: Kyle Sluder <email@hidden>
- Date: Thu, 19 Feb 2009 19:58:21 -0500
On Thu, Feb 19, 2009 at 7:42 PM, Ken Thomases <email@hidden> 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 (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