On 09/05/2013 04:39 PM, Thomas Voß wrote: > Hmmm, effectively extending the ANR approach to non-UI bits. That is > interesting idea. Admittedly, an app could work around that, too, but > hey :) Further extending on the idea: Whenever we identify a process > that is using too much CPU over a certain period of time, we start > ptrac'ing it and send over a SIGXCPU. If the process hasn't setup a > signal handler for that signal and we find out (waitpid and friends), > we can assume that the process is either not behaving in the Ubuntu > way _or_ something is wrong and we SIGKILL. Alternatively, we could > use SIGUSR1/SIGUSR2. > > Makes sense?
Makes sense, but there's the risk that apps which use long-running jobs will install their handler at startup, and won't remove it once the computation is done; so, for such apps, you won't be able to find out if they get stuck in some busy loop. An hybrid approach would be to have a couple of APIs: ubuntu_app_start_cpu_intensive_task() ubuntu_app_end_cpu_intensive_task() where the first one installs the signal handler, and the latter removes it. The signal handler should actually be reference-counted, so that you need to call ubuntu_app_end_cpu_intensive_task() as many times you called ubuntu_app_start_cpu_intensive_task() in order to remove the handler. Ciao, Alberto -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
