← Back to team overview

ubuntu-phone team mailing list archive

Re: Background services: a problem that we need to face

 

On Wed, Jun 25, 2014 at 11:17 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> On Wed, 2014-06-25 at 17:10 -0300, Sergio Schvezov wrote:
>> On miércoles 25 de junio de 2014 16h'29:10 ART, Rodney Dawes wrote:
>> > On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
>> >> On 14-06-25 02:11 PM, Rodney Dawes wrote: ...
>> >
>> > No. It means the app is running, whether it is in the foreground or
>> > background. It doesn't need to be the current foreground app. Running
>> > apps, the automotive data logging app I linked, etc… continue running
>> > even in the background, to be able to monitor location, log performance
>> > data from BT/ANT+ devices, and perform actions based on location or the
>> > data stream from a connected device.
>>
>> Please take the time to read the full length of the document I linked to.
>
> The Apple doc? It clearly indicates to me that long-running background
> processes remain running.
>

Okay, let's take a look at the iOS documentation:

https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW47

And let's have a look at the table in section "Managing App State
Changes", specifically entry "Background":

The app is in the background and executing code. Most apps enter this
state briefly on their way to being suspended. However, an app that
requests extra execution time may remain in this state for a period of
time. In addition, an app being launched directly into the background
enters this state instead of the inactive state. For information about
how to execute code while in the background, see “Background Execution
and Multitasking.”

The background execution state is not a persistent state, it is a
transitional one, with "Suspended" (a.k.a. SIGSTOP'd) being the usual
follow-up state. Also note that the system reserves the right to
transition apps from "Background" to "Suspended" or even "Killed" at
any time. The grace period that apps can request cannot be extended
indefinitely. Obviously, both iOS and Ubuntu try to keep as many apps
as possible in the "Suspended" state to ensure fast resurrection
(i.e., SIGCONT) of apps. However, in the case of Ubuntu, if memory
pressure arises, the oldest suspended apps are automatically killed.

Please also note that our lifecycle explicitly states: We only
guarantee an app to be running while it is in the foreground. If it is
in the background, it may or may not be running. This is exactly the
same contract between the apps and the system as on iOS. Sure, we
might think about extending grace periods before suspending an app,
but we are free to do so as we did not, should not and will not give
any guarantee on the amount of resources granted to an application
running in the background.

> I think maybe there is some confusion in this thread about what
> "running" means. A sleeping/stopped process is still running and has a
> PID.

The difference between sleeping and stopped is significant, though.
Sleeping means cooperation by app authors which we cannot assume.
Stopped can be and is enforced by the system according to our
lifecycle state machine.

> A killed process is not running. Apps which do not register
> themselves as long-running background processes will certainly be
> stopped indefinitely, or killed on iOS.
>
> However, it is not clear to me if iOS is actually stopping processes, or
> if they are just sleeping and waiting for the main loop to send an
> event, when they are registered for long-running background processing.
> It is clear that it does wake the process and call a callback in that
> process, depending on the task it is registered for, though.
>

They are transitioned to suspended once their grace-period has ended.
One thing to point out: our lifecycle allows an app to be woken up (by
calling out to lightweight helpers) whenever important events
happened. The set of important events is defined by the system
services that Ubuntu offers. While app authors will certainly say:
*My* app needs more, because *my* app does super important and useful
things with event x,y,z in the background, I don't think that we
should give in to that. As pointed out earlier: Just periodically
waking up entire applications is a naive sampling approach to the
problem of identifying and understanding events and services that are
of real use to the *user*.

Thomas
>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References