On Wed, Sep 10, 2008 at 8:04 AM, Ken Thomases <[EMAIL PROTECTED]> wrote: > On Sep 10, 2008, at 4:19 AM, Wesley Smith wrote: > >> I'm trying to figure out how I can have my app run a timer that never >> suspends when the user interacts with menus and the like. > > You can use -[NSRunLoop addTimer:forMode:] to schedule the timer on > additional run-loop modes. You might want to use > NSEventTrackingRunLoopMode, for example.
thanks, I'll give it a shot. > > Whether this is a good idea or not is another question. Remember, no matter > what mode(s) a timer is scheduled in, there's no guarantee that it will fire > at any given rate. At any given moment, the application may not be idle in > its event loop -- it might be doing processing or handling some other event. > Also, depending on what you're doing in response to the timer firing, it > might not be appropriate during menu tracking, etc. So, depending on what > you're trying to achieve, you may be asking the wrong question. > Fair enough. Essentially this timer is what drives everything in the app from OpenGL buffer swaps to modifications to the DSP audio graph (it does not process audio, just a high-level representation of the unit generator graph that exists in the DSP thread). In the Cocoa world, would I be better off using a secondary thread for this timer? I was a bit concerned about how things like NSWindow/NSView would behave in this instances, being driven from one thread and receiving UI from another. Another option would be to use signals like SIGALRM. Given this, would I be abusing NSTimer and the main NSRunLoop? thanks, wes _______________________________________________ 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 [EMAIL PROTECTED]
