ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

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