Chris Suter wrote:
Hi Kyle,
On Wed, Mar 11, 2009 at 5:02 PM, Kyle Sluder <kyle.slu...@gmail.com> wrote:
Well, there is a sentence directly below that list that says the following:
"Because timers and other periodic events are delivered when you run
the run loop, circumventing that loop disrupts the delivery of those
events."
That sentence implies that the run loop must be run, either manually
or as the result of input coming in on an input source (which timers
are not), in order for the timer to fire.
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.
Regards,
Chris
Yes I think by 'run' they mean you have called one of the NSRunLoop
methods which start with the word 'run', not that it's poked into action
and executing code. It can be 'running' and fast asleep.
What's the dummy source requirement? The NSRunLoop runxxx methods all
say 'If no input sources or timers are attached to the run loop, this
method exits immediately', which indicates a Timer alone is enough to
keep the runloop running. I know however that a timer firing will not
cause methods like runMode:beforeDate: to exit.
It would be odd if runloops only checked for timers when they happen to
have been woken up by some other random event on another input source,
you'd get totally inconsitent timers, the timer firings themselves must
actually awaken the runloop from sleep.
_______________________________________________
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
