Re: File IO preventing sleep
Re: File IO preventing sleep
- Subject: Re: File IO preventing sleep
- From: Dean Reece <email@hidden>
- Date: Wed, 22 May 2002 23:46:21 -0700
On Wednesday, May 22, 2002, at 11:09 PM, Lisa Zorn wrote:
On Monday, May 20, 2002, at 09:51 AM, Matt Watson wrote:
On Monday, May 20, 2002, at 09:33 AM, Dean Reece wrote:
You might try stat'ing the file instead of reading it.
Or fstat() since you already have the file open...
Matt & Dean, thanks for the stat/fstat suggestion.
This certainly helps -- it's ... kind of... fixed. However, sometimes
it takes longer than it should. For example, I have my system set to
sleep after 5 minutes but many a time, after my last read, it'll go dim
in 5 minutes and take another 5 minutes to sleep. I receive the IOKit
messages at this point -- 10 minutes after my last read.
What version of the OS is this? The algorithm has been refined over the
releases, and this sounds like an older behavior. It should be lower on
newer builds, though the exact timing will depend on all the details and
will vary from run to run.
This bothers me because I don't know what exactly is happening (and my
program's users are going to complain that it's not going to sleep
probably, and I don't know how it'll scale with longer time-to-sleep
preferences), and it's so excruciatingly time consuming to test.
There were some utilities floating around a while back that allowed you
to set the timings down to 1 minute to expedite such testing. You might
check the archives...
Is there anything I can do to figure this out? Any other suggestions?
Why is there separate timing for dimming versus sleeping?
What exactly is going on when it dims versus when it sleeps?
This is all part of a complicated dance done to determine the activity
state of individual subsystems -vs- the whole system. So, the disk will
spin down after some period of inactivity. Likewise the screen dimming
is driven by (in)activity in the HID system. System sleep is a
combination of the two, as well as other variables, and so the system
will sleep approximately n minutes after the last disk I/O or HID
activity. The algorithm is a bit more complicated than this, but you
get the idea.
Idle sleep logic is very tricky to get right, because you've got to
balance the user experience of having the system sleep when expected
against preventing sleep when it is unexpected. It is hard to get this
just right by watching block I/Os flow by.
In your case, I'd say do the absolute minimum number of I/Os that you
have to, and avoid doing them repeatedly so that you don't completely
block system sleep. If it causes a slight delay in system sleep, users
will probably not even notice (much). There are plenty of cases where a
simple thing can wedge the system awake: Leaving a browser open to a
webpage that causes periodic disk activity; An email client that checks
for mail once a minute and touches it's local cache every time;
scripting utilities that generate fake mouse events (stretching a bit).
The point is that users will mostly figure these things out and/or live
with them. We are always looking for superior algorithms for predicting
the users future desires, but it is not a perfect science, and so you
sometimes get effects like you are seeing.
Cheers,
- Dean
_______________________________________________
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.