Killing activities when memory gets short

[Tiago Marques]

On Sun, Aug 8, 2010 at 8:33 PM, 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.
>

Good point. In my mind this was an opt out for a process LRU that wouldn't
be filling up the whole memory needed by another one, in that case the
confirmation would become a notification.
I think it's better to notify than to keep the user clueless, thinking that
the device is somehow broken.


>
> > 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.
>

Indeed. But this behaviour has to be properly explained to the user somehow,
if previous state restore isn't possible at all.

Best regards,
Tiago


>
> Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100826/78cdf8f0/attachment.html>