> On Wed, Aug 04, 2010 at 12:29:36PM -0700,
david@lang.hm wrote:
>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>
>>> 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.
>>
>> why would you trust it to take a wakelock, but not trust it the rest
>> of the time?
>>
>> in my proposal I'm saying that if you would trust the application to
>> take a wakelock, you instead trust it to be sane in the rest of it's
>> power activity (avoiding polling, etc) and so you consider it for
>> sleep decisions.
>
> The word "trust" does not appear to be helping here. ;-)
>
> The VOIP application acquires a suspend blocker when it needs to prevent
> the system from suspending, and releases that suspend blocker when it
> can tolerate the system suspending. It is important to note that while
> the VOIP application holds the suspend blocker, the system won't suspend
> even if it is completely idle (for example, if the VOIP application uses
> blocking system calls, during the time that the VOIP application is
> waiting for its next event).
