| |||||||||||||
Blocking suspend blockersBlocking suspend blockersPosted May 20, 2010 7:15 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Blocking suspend blockers by neilbrown Parent article: Blocking suspend blockers
I may be misreading things as well, so it will be interesting to see others comments on this.
As for why drivers need to block suspend, if you set the system to be hyper eager to suspend, then you can't count on getting anything finished unless you block suspend.
if for example, your driver needs to send a string of bytes to your GPS chip to initialize it, having the system sleep in the middle can leave you with a uninitialized device that won't work when you wake up and pick up where you left off, so you need to block suspend while you do this 'critical, uninterruptible' work
the problem that I see is that I haven't seen anything that would prevent an application from claiming that everything that it's doing is critical. It's definitely easier for joe random game developer to just tell the system to not suspend while the game is running than it is to properly handle being suspended.
sometimes an app blocking suspend is the right thing to do (think a 'flashlight' app that just displays an all-white screen and prevents the system from sleeping until you do something to turn it off), but without any way for the system to prevent abuse, it's only going to be a short time before apps start abusing it.
(Log in to post comments)
Blocking suspend blockers Posted May 20, 2010 9:39 UTC (Thu) by farnz (guest, #17727) [Link] The trick, in Android world, is that only a limited set of known processes can actually set suspend blockers (just as in POSIXy Linux world, only a limited set of processes can write to /dev/sd*). Everyone else who wants to block suspend has to ask one of the privileged processes to set a block for them, using Android's RPC mechanism. An Android app comes with a manifest file, and in that manifest file, you must declare if you wish to take out a suspend blocker. This translates in UI terms to a warning when the application is installed, telling you that the application can "prevent phone from sleeping", and to Android's "where's my battery gone" UI and APIs blaming applications that hold a suspend blocker for the resulting power consumption. Thus, on a phone, if you take out a suspend blocker via the RPC mechanism, you get blamed whenever the user asks the phone "why's my battery life poor?", even if it's another app hammering the CPU and keeping you out of idle. The hope is that this will be enough to stop application writers from using suspend blockers when they're not needed.
Blocking suspend blockers Posted May 20, 2010 18:33 UTC (Thu) by felipebalbi (subscriber, #56613) [Link]
That's not what some android developers said on the discussion, they said anyone can take a suspend blocker and like I replied to them, if you only want suspend blockers to pretty print on UI, there are other less invasive and transparent to apps mechanisms to do so. You don't need opportunistic suspend and suspend blockers.
Blocking suspend blockers Posted May 20, 2010 20:12 UTC (Thu) by broonie (subscriber, #7078) [Link]
For all practical purposes any app can take a suspend blocker - there's no opportunity for users to tweak the set of permissions an application has, it's fixed by the app developer. However, the UI does warn the user during installation that the app might do this and does provide the accounting that's been discussed.
|
|||||||||||||