ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #03996
Re: Catching CPU run-aways on Touch
On Thu, Sep 5, 2013 at 3:25 PM, Joe Talbott <joe.talbott@xxxxxxxxxxxxx> wrote:
> On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
>> On 09/05/2013 12:42 PM, Colin Ian King wrote:
>> > On 05/09/13 10:33, Colin Ian King wrote:
>> >> On 05/09/13 10:23, Evan Dandrea wrote:
>> >>> Stuart Langridge brought up an interesting idea for this on IRC, which
>> >>> I'm copying here rather than having more side discussions:
>> [...]
>>
>> Oops, I should have read the whole thread before posting my previous
>> e-mail. :-)
>>
>> > Anyhow, I still think myAppIsRunning() is open to abuse as it will in
>> > time be lavishly added to all sorts of tight loops that suck CPU, which
>> > just adds more overhead on the long run.
>>
>> Well, if we don't have a myAppIsRunning() API, apps can simply busy-loop
>> whenever they want, so I don't see much harm in adding this API.
>> We could also protect it with apparmor, so that the usage of this API
>> must be explicitly declared in the application's manifest file (and then
>> we could question whether the app has any reason to use it).
>>
>> Note however that this would still solve the issue of detecting apps who
>> use too much CPU time because of some bugs, which I think was the
>> original goal.
>
> Would a watchdog sort of timer work better here? One where the OS sends
> a signal to a high CPU usage app and if the app doesn't respond to the
> signal we have a better clue that something is amiss.
>
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?
Thomas
> Thanks,
> Joe
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help : https://help.launchpad.net/ListHelp
Follow ups
References