On Wed, Aug 04, 2010 at 12:15:59PM -0700, david@xxxxxxx wrote: > On Wed, 4 Aug 2010, Matthew Garrett wrote: >> No! And that's precisely the issue. Android's existing behaviour could >> be entirely implemented in the form of binary that manually triggers >> suspend when (a) the screen is off and (b) no userspace applications >> have indicated that the system shouldn't sleep, except for the wakeup >> event race. Imagine the following: >> >> 1) The policy timeout is about to expire. No applications are holding >> wakelocks. The system will suspend providing nothing takes a wakelock. >> 2) A network packet arrives indicating an incoming SIP call >> 3) The VOIP application takes a wakelock and prevents the phone from >> suspending while the call is in progress >> >> What stops the system going to sleep between (2) and (3)? cgroups don't, >> because the voip app is an otherwise untrusted application that you've >> just told the scheduler to ignore. > > Even in the current implementation (wakelocks), Since the VOIP > application isn't allowed to take a wakelock, wouldn't the system go to > sleep immediatly anyway, even if the application gets the packet and > starts the call? What would ever raise the wakelock to keep the phone > from sleeping in the middle of the call? There's two parts of that. The first is that the voip application is allowed to take a wakelock - but that doesn't mean that you trust it the rest of the time.The second is that the incoming network packet causes the kernel to take a wakelock that will be released once userspace has processed the network packet. This ensures that at least one wakelock is held for the entire relevant period of time. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
