...
No, but I didn't assume that your wakelock-holding processes depend on the
other processes in a way that might prevent them from acquiring or dropping
a wakelock.
...
That doesn't matter. In the opportunistic mode you don't need to write into
/sys/power/state to start suspend, this is done by the kernel automatically as
soon as the last wakelock has been released (at least this is my assumption
about how this works). Now, at this point the processes that don't use
wakelocks can't really prevent themselves from being frozen and only the
wakelocks users can do that. So, if a wakelock user depends on a process
that doesn't use wakelocks in such a way that (because of that dependence) it
can't acquire its wakelock while processes are being frozen, things don't work
as they are supposed to.
This only means that the theoretical failure you gave as an example doesn't
happen in practice. No problem, then. :-)
And how is this different from an approach with cgroup freezing? Apps that
use wakelock within the current framework would use "freeze locks" to prevent
the "untrusted" part of user space from being frozen or to thaw it. Where's
the problem, then?
Rafael
--
