On Mar 11, 2009, at 1:17 AM, Kyle Sluder wrote:
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.
No, it's not.
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?
The dummy input source doesn't need to prod the run loop, ever, at
all. The timer fires completely independently of any other run loop
source, and doesn't need any prodding.
There is, in fact, no need for a dummy input source. A timer is
sufficient to keep a run loop "running", which is to say blocked. I
was one of the incorrect folks who propagated this myth,
unfortunately, but was corrected. Either a dummy input source such as
a port _or_ a timer is enough to keep a run loop -run... method from
immediately exiting.
Although these details should not be relied upon, under the hood a run
loop is implemented in terms of Mach message ports. A run loop blocks
by calling mach_msg() to receive a Mach message on any of a set of
ports. If there are timers in the run loop mode, then the time
interval until the next needs to fire is passed as a timeout to the
mach_msg() call. This is how a run loop can block waiting for any
source or timer. (If sources or timers are added from another thread,
which is legal with CFRunLoop but not NSRunLoop, then the other thread
needs to wake the run loop, probably by sending a message on a Mach
port set aside for that specific purpose. That port will be in the
set being waited on in mach_msg(), thus unblocking it.)
My reason for discussing these internals is to illustrate how run
loops can block on timers with no CPU usage.
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.
All irrelevant, as there's no need for any signaling of any run loop
input sources to allow timers to fire.
Regards,
Ken
_______________________________________________
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
