872177 - Freeze background apps that aren't holding a "cpu" wakelock

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P3)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We should freeze background apps that the user isn't interacting with. We'll probably need applications to be able to signal to the system that they are doing some important work (such as saving data to disk) and shouldn't be frozen, a good way of doing that would be to rely on the "cpu" wakelock.

This would both result in better performance of foreground apps, and reduce battery usage from background apps.

While apps could already do much of this themselves by simply "stop doing anything" when they receive a visibility-change event, this is a lot of work for them. Work that many developers won't bother with, won't know that they should do, or won't get right.

We'll probably need other smarts too. For example apps that are using the "content" channel, and thus still play audio when put in the background, should not be frozen. And apps that have a running IDB transaction should not be frozen as long as that transaction is active (which the API forces to be a short period of time).

We might even want to try to be clever about active network requests. Either by not freezing the app while it has running HTTP requests, or by somehow buffering responses in the parent until the child is woken back up.

Comment 1

[Justin Lebar (not reading bugmail)]

We definitely need to do this, given how much battery we've seen sucked up by e.g. the music player app merely updating a counter once a second.

You could imagine a simple countdown timer app similarly sucking up battery.  We'd put the CPU to sleep when the device's CPU goes to sleep, but if the CPU happens to be on due to e.g. the music app, we're in big trouble.

Comment 3

[Sotaro Ikeda [:sotaro]]

Is there a way to keep app ruuning in background even when app do not hold "cpu" wake lock? If all background running apps needs to hold "cpu" wake lock, cpu can not come into deep sleep state. It could affect to power consumption.

Comment 4

[Justin Lebar (not reading bugmail)]

This is a large change that I don't think we should target for tef unless it's an absolute product requirement.

Comment 5

[Daniel Coloma:dcoloma]

(In reply to Justin Lebar [:jlebar] from comment #4)
> This is a large change that I don't think we should target for tef unless
> it's an absolute product requirement.

Moving to leo triage

Comment 6

[Alex Keybl [:akeybl]]

This wouldn't be a blocker, if we want to propose a fix once completed, please nominate for approval.

Comment 7

[Dave Hylands [:dhylands]]

I mentioned this in the email thread, but I figured I'd repeat it here.

One way would be to have the event loop of each thread test a volatile boolean, and if true, then block on a mutex.

Some "freezer" thread would listen for events to freeze/thaw and would acquire the mutex and set the boolean. Then when it received the thaw request from the parent it would clear the boolean and release the mutex.

My gut tells me that we'll run into some complications, but this seems like an approach which could at least allow us to try it out.

Comment 8

[[:fabrice] Fabrice Desré]

Dave, probably a silly idea, but since we run only one app per-process could we not just send SIGSTOP and SIGCONT to control the process state?

Comment 9

[Dave Hylands [:dhylands]]

(In reply to Fabrice Desré [:fabrice] from comment #8)
> Dave, probably a silly idea, but since we run only one app per-process could
> we not just send SIGSTOP and SIGCONT to control the process state?

The problem will be if the process holds any out-of-process locks.

genlock is a classic example, although it may not be applicable for content processes. For genlock you issue an ioctl to acquire the lock and another ioctl to release it.

If the SIGSTOP is received between the two ioctl calls, then you wind up suspending the process while its holding the lock.

File locks (acquired and released through flock) are another example.

Anything that is purely in-process will be fine. Its just the out-of-process locks that can cause problems.

The out-of-process locks may be an issue with the technique I proposed as well.

Holders of wakelocks, both android wakelocks and PowerManagerService::NewWakeLock would also suffer.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Most, if not all, out-of-process locks should be short lived, that's how we've designed WebAPIs. So one solution might be to prevent any process that holds out-of-process locks from getting frozen.

Comment 11

[Dave Hylands [:dhylands]]

So I know that I used Wakelocks to implement something I call a volume lock.

A volume lock is used to prevent a volume from being shared with the PC while the volume lock is held.

These are (or can be) used by bluetooth when transferring a file to device storage to prevent the storage are from being taken away while its writing a file (or perhaps by video while recording)

A volume lock is an example of an out-of-process lock that might be held for more than a "short" time, depending on your definition of short.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Good point. Though during bluetooth transfer we probably don't want to freeze the background process, so that app should likely hold a "cpu" wakelock during the transfer.

Comment 13

[BMO Automation]

Firefox OS is not being worked on