[Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 8 August 2010 20:33, Marco Pesenti Gritti <marco at marcopg.org> wrote:
> On 8 Aug 2010, at 18:40, Tiago Marques <tiagomnm at gmail.com> wrote:
>> The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc.
>
> An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside).
>
>> Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time.
>
> Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst.

Activities already write_file when they lose focus, they could
write_file periodically or at least when warned of low memory.

>
>> Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no?
>
> Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex.
>
> As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration.

Separating the activity from the service would help here. In the case
of music, MPD would use a lot less memory than one of its GUIs.

>
> Marco
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>