I am not sure if SIGSTOP is the right solution. Sure it does freeze the application, but does it also put the application’s memory into the disk?
Using SIGTERM would probably be a much better idea since the developer is able to intercept this call. Still, having a lifecycle that works on top of SIGTERM would make saving data and states much more eaiser.
So the advantage of SIGSTOP is it doesn’t require modifying the application at all, just a quick review of it to see how it behaves. It doesn’t automatically swap out the program’s pages, but proper cgroup setup would mean as soon as the memory is needed for something else, the stopped program will get swapped out. Using SIGTSTP would let an application decline the stop request too.
Note that writing the memory to the disk if the memory is not needed for anything else is the wrong solution.
It’s an okay solution for applications that were not designed to run on a mobile device.
With that being said, I still think it is a bad idea to freeze an application without letting the app know. Apps should be able to save data and disconnect from a server/device before it goes into a frozen state.
If an application is taking too long to quit, kill it. That how iOS handles this situation.
That’s the reason for the behaviour review. A real time chat application probably wouldn’t like being SIGSTOPed, as it’s network layer will timeout. Then again, a decently written one will put itself to sleep using either recv or poll, so there’s no need to stop it. Meanwhile, a calculator program can be quite safely stopped and resumed when the user switches back to it. Easy general rule is if the program has open network connections, it probably shouldn’t be stopped.
A more advanced system could easily exist via dbus, along side the more primitive version, but that would require the application in question to support it, which means editing and recompiling. Probably worth it for the most commonly used programs, but not feasible for everything.
Killing misbehaving programs is generally a bad idea, unless the user specifically asks to do so. Sometimes misbehaving really means ‘trying hard not to corrupt data’.
I don’t disagree, but it doesn’t seem to be a problem with iOS applications.
Even if an application is well optimized, It should not stay alive if it doesn’t need to stay alive.
I totally understand desktop applications not really caring about moble-like lifecycles. It is fine if they are not interested in support it; with that being said, mobile applications need this. Mobile applications don’t have the same freedom as desktop application and should not be treated as such.
When an application is no longer in view, it means I am not interested in using it. Mobile applications should be aware of this.
iOS applications are written with that sorta in mind, and are derpy as can be to start with. In general, it’s easy if the assumption is the application can’t have anything important because the user doesn’t control it anyway, so just store everything in the cloud. That doesn’t really hold here.
Define need to stay alive. If you kill the application, you have to restart it when the user wants it again. If it’s asleep, it consumes no power. If there is a need for additional free memory, there is a mechanism to politely ask programs to free some, which can prompt them to exit. There’s also zram, and swap files, which can free memory from almost any sleeping program. Obviously, if the application is not going to be used for an extended period, closing it is fine, but it’s better for the user to have a clear way to indicate that, rather than trying to guess.
It’s certainly a good thing to have the mobile applications as energy efficient as possible, it’s a matter of effort required vs marginal reward. The SIGSTOP method will work for probably 90% of energy intensive applications, I use it for power saving with laptops regularly. It even works for a fair number of networked applications, if they can handle a network connection vanishing out from under them, they’ll be fine. If there is an application that’s likely to be open even an hour a day on most L5s, and it neither puts itself to sleep, nor handles SIGSTOP in a sane fashion, it’s probably worth fixing it. If it’s open for 10 minutes a week, and rarely backgrounded, it’s probably not even if it is a mobile exclusive application.
So you don’t want realtime notification from discord/slack/sms whatever, because the application got stopped/killed when you switched away from it? It should stop calculating its screen contents, and it should put itself to sleep via select or similar until a message comes in, but that isn’t the same as completely parking. Note that, if it sleeps properly, it will literally use 0 CPU cycles until the kernel wakes it up to handle a signal or a network message.
This is simply not true for me. Example: get mail. It takes long over slow network. So meanwhile I’d switch over to other applicaiton, or turn the screen off to save battery. I expect that after an hour, when I remember to check my mail again, it will be synced to the poin in time when sync was initiated, not aborted midway because I pushed the power button to turn off the screen.
In general, it is impossible by the OS to know when application is needed or not. This decision should be left to the user.
On my current outdated phone, even browsing takes enough time to warrant switching screen off. Can’t do that because of the rule “out of focus, out of cpu”. Very annoying.
I can still see SIGSTOP leaving holes.
I don’t agree with you at all with this. Not all iOS applications use the cloud and they can save data just fine.
I never said I didn’t want background services. But if you want your app to support background services, it should be coded as a separate service, not coded into the GUI application.
If you want to push for SIGSTOP, at least give the app the option know that it is going to be SIGSTOPed. It is not enough to determine when an application should SIGSTOP based on their behavior.
Something like nohup for shell applications would be useful too, as there are things like SSH and file transfers I may also want to keep open in the background.
There are two signals used to pause a program. SIGSTOP doesn’t get delivered to the program, it just gets paused. SIGTSTP does get delivered to the program, if the program registers a handler for it. The latter is what is sent via ^-z in the shell. I think that’s the better one to send, as it would let programs choose to sleep, or not.
You’re half right here; the unix approach is the right way. The problem with writing a separate service for background tasks is you’ll end up with code duplication instead of reuse, which is a serious bug surface. Instead, it’s better to write a CLI or headless program that can do basically everything. The GUI then becomes a thin shim over the top of it, which can come and go without affecting the underlying program.