On Wed, Jun 25, 2014 at 11:17 PM, Rodney Dawes <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
