On Tue, Mar 10, 2009 at 11:38 PM, Michael Ash <michael....@gmail.com> wrote: > The notion that adding a timer to a runloop would somehow cause that > runloop to suck up CPU time when the runloop is idle is nonsensical. > The whole point of the runloop is that it sleeps the process until > some activity is required. A background process sitting on a timer > *will* take up various resources (memory, file descriptors, kernel > structures, etc.) but CPU time is not among them.
That's not what I said. What I said was that you cannot add a timer to your runloop and expect it to sit blocking on it until the timer fires. That's not how timers operate. You will need to periodically run the runloop in order to get your timer to fire. If you are doing this in an application, then the event-processing functionality of the runloop will take care of it. Otherwise, you will need to run it yourself. Either way, you will need to periodically poke the runloop, which on it's face can't take 0.0% CPU. Your app will persistently wake up (and our friend Nyquist has proven that in order for this to work it must wake at least twice as often as you want the timer to fire). --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