Re: Background Process?
Re: Background Process?
- Subject: Re: Background Process?
- From: Kyle Sluder <email@hidden>
- Date: Wed, 11 Mar 2009 02:17:12 -0400
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?
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 (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