[Sugar-devel] Fwd: Activity startup idea

[Tomeu Vizoso]

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
>>>> analyzing
>>>> 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
>>> launch.
>>
>> 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
>> work.
>
> 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.

Thanks,

Tomeu