Re: NSTimer and deep sleep
Re: NSTimer and deep sleep
- Subject: Re: NSTimer and deep sleep
- From: Chris Kane <email@hidden>
- Date: Sat, 25 May 2002 23:28:23 -0700
Timers won't fire while the computer is asleep, and in fact the system
clock is stopped during sleep (where "sleep" means SLEEP, not NAP or
DOZE mode, on ppc). Timers means kernel timers, and the CF and Carbon
and Cocoa timers all based on them. The stopping is the system clock's
defined semantic.
When the computer wakes, the system clock just picks up from where it
stopped, and thus currently so do timers. However, most people think of
timers as firing relative to the calendar clock (what I also sometimes
call "civil time"), which has units like seconds, days, and so on.
gettimeofday(), CFAbsoluteTime, NSDate, and others are all calendar
clock-based APIs, and the APIs of the CF and Cocoa timers are based on
these (and Carbon too I think but I don't recall off hand).
So these user-land timers should very probably update the kernel timers
with new system clock dates for their next calendar-clock-based firing
when the computer wakes. There are a few troublesome things about that
however:
1) The notifications of sleep/wake come via IOKit, which is layered
higher than CF (the basis for those other timers), so CF would have to
(a) dynamically load IOKit into every process which isn't already
pulling it in [potentially a performance hit] to register for these
notifications and (b) do up-calls to IOKit after dynamically looking up
the needed functions by name [also a perf hit].
2) On wake, CF will then be walking through several lists of timers,
touching memory, and doing a bunch of kernel calls to reset the timers,
in every process using CF run loops on the system (many daemons in
addition to apps). Thrash, thrash, thrash. And wake slows down. Plus
of course some timers' fire dates will have passed, and they need to
fire right away.
3) Compounding all this, the calendar clock doesn't update to the actual
civil time at wake for several seconds after wake starts, so the updated
information the timers need isn't available right away on wake, when the
notification arrives.
So, I haven't fixed the bug yet. Wake is fairly snappy now, and it's
guaranteed it won't be as snappy afterwards (wake a Mac OS 9 system from
sleep for comparison). Lots of things wanting to know when the system
wakes up is not good for the the wake experience, period. This won't be
fixed for Jaguar, but it might be for a later release. [In any case,
timers aren't going to fire while the computer is asleep.]
Chris Kane
Cocoa Frameworks, Apple
On Thursday, May 23, 2002, at 06:58 PM, Greg Anderson wrote:
I've got an app I'm working on that runs as a background-only app
and runs a timer (it changes the desktop picture after a time interval).
My problem is that when a computer is put into deep sleep, the timer
stops timing (at least this is what I'm observing), and thus if it was
set to rotate "every day" and the computer was awake for 6 hours, asleep
for 18, it wouldn't actually change the picture for another 18 hours of
computer-awake time.
My question is: is there a "good" way to handle timer functionality
when the computer's asleep? My first thought was to keep track of when
the timer starts, and run yet another timer on say a once a minute loop
to check and see if the time interval specified has passed. But that
starts to seem a little kludgey. Unless we get an event on wake... but I
digress.
Any advice/ideas/experience/limericks would be appreciated. (Wait,
maybe not the limericks). Thanks.
Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.