On Wed, Mar 11, 2009 at 2:08 AM, Chris Suter <csu...@sutes.co.uk> wrote: > Obviously, the run loop has to run, but you don't need events to be > received or processed for the timer to fire. You need at least one > event source, possibly a dummy one, but it doesn't have to do anything > and so the CPU usage whilst waiting for the timer to fire will be > zero.
That's all well and good, and in line with what I've been saying. However, there are two problems: 1) How does your dummy input source know when to prod the runloop so that the timer can fire? At that point, why not just use whatever mechanism you're using to signal the input source to just run whatever code it is you want? 2) There is still processing time involved when signaling your input source. Since information theory dictates that you must signal your runloop input source at twice the frequency (2n Hz) of which you want your timer to fire (n Hz, the Nyquist frequency), you will on average be spending half the time your process is awake doing nothing but going back to sleep. While this time is certainly miniscule, it is not zero, and it involves at least two context switches through the kernel, once on the way into sleep, and once on the way back out. This activity will involve moving bits around through the CPU. If you leave that responsibility to launchd, on the other hand, you are no longer responsible for that activity and you eliminate the other overhead of leaving your process hanging around in a suspended state instead of using the existing resources consumed by launchd. --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
