> On Wed, Aug 04, 2010 at 12:15:59PM -0700,
david@lang.hm 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.
