[Sugar-devel] Fwd: Activity startup idea
tomeu at sugarlabs.org
Mon Mar 9 13:10:30 EDT 2009
On Mon, Mar 9, 2009 at 17:52, Wade Brainerd <wadetb at gmail.com> wrote:
> On Mon, Mar 9, 2009 at 9:56 AM, Gary C Martin <gary at garycmartin.com> wrote:
>> On 9 Mar 2009, at 13:28, Tomeu Vizoso wrote:
>>> On Tue, Feb 24, 2009 at 03:38, Wade Brainerd <wadetb at gmail.com> wrote:
>>> What about watching system resources and refusing to start a new activity
>>>> when there isn't enough RAM available to launch it?
>>>> It should be pretty straightforward to add a required_memory field to
>>>> activity.info - it would be a simple, approximate high water mark memory
>>>> usage for a given activity. The default could be determined by
>>>> the basic activities - maybe 20mb would be good?
>>> Are we sure this is a good experience for our users? I remember that
>>> in the old MacOS times, I found a bit tiring to have to go to the
>>> applications' info panel to lower the memory limits so the app could
>> Yea, that was rather a frequent support call back in my early Adobe days
>> :-) Set it too low and they can't open some document, to high and they can't
>> run the other couple of applications they needed open at the same time to
> Even a warning alert would be better than nothing.
> Your computer is too low on memory to start this activity.
> Are you sure you want to start Browse?
This I like more than refusing to start the activity. And Ben's
suggestion about being the shell to calculate it is interesting.
> It happens to me at least once every couple of days on build 767...first the
> UI freezes, then the trackpad stops responding, and if I'm lucky I can
> manage to Ctrl-Alt-F1 and kill Browse before having to just hard power off.
> And that's just with GMail (in Browse), a Terminal, and Typing Turtle
> (which is admittedly a memory hog due to all the cached key graphics).
Wonder if compcache would help you there?
> Also, I think we should really consider implementing that kernel OOM watch
> feature. Activities save their state when you tab away from them, so in a
> lot of cases it's safe to just kill background activities.
Yes, I like this scenario. If we can give a low kill priority to the
shell, wm, X, etc and to the activity in the foreground and a high
kill priority to the activities in the bg, I think that stability will
get much better. But in that case we need to provide a good way to
explain to the user that a background activity was killed and why.
More information about the Sugar-devel