Re: Background Process?
Re: Background Process?
- Subject: Re: Background Process?
- From: Roland King <email@hidden>
- Date: Wed, 11 Mar 2009 14:36:03 +0800
Kyle Sluder wrote:
On Wed, Mar 11, 2009 at 2:08 AM, Chris Suter <email@hidden> 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?
Right - here is exactly the difference in my understanding of it. You
are saying that the runloop goes to sleep and only when a 'real' input
source fires does it wake up and and if the time is now greater than the
next expiration of any timers, they get processed. But I don't think
that's true at all, it's not what the documentation says, it says the
thread sleeps until, amongst other things, 'a Timer fires'.
If you need a dummy source at all just to keep the runloop from exiting,
it doesn't have to do a thing. Timers themselves wake the runloop.
How exactly the timer firings wake the loop up I don't know, I've always
assumed in the middle of the code there's something like a select() call
with a timeout equal to the time interval to the next timer scheduled to
fire, if no port-based sources make the select return, it times out, the
thread wakes, and goes and fires the timer. But I'm sure it's horribly
more complicated than that.
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.
Obviously if my understanding of 1) above is correct .. this isn't a
issue, you don't have to use the dummy input source to wake the runloop
to poll the timer, there's no work performed here at all.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden