[Sugar-devel] Fwd: Activity startup idea

[Gary C Martin]

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:
>> On Mon, Feb 23, 2009 at 5:57 PM, Luke Faraone <luke at faraone.cc>  
>> wrote:
>>>
>>> On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche  
>>> <cafl at msbit.com>
>>> wrote:
>>>>
>>>> Spend a few hours in a kindergarten classroom.  It doesn't work to
>>>> prevent repeated launching of activities and ultimately a need to  
>>>> reboot.
>>>
>>> Is there anything sugar can do in this regard?
>>>
>>> Would this activity starting logic work:
>>> * If no activity instances are running, start it.
>>> * If an instance has been "started" already but the process has  
>>> not yet
>>> signaled on the dbus that it is "running", ie drawing windows etc.  
>>> for the
>>> user, switch to that instance
>>> * If an instance has been started and is running, start a new  
>>> instance.
>>> (*or* send a "start new instance" request to the existing  
>>> instance, which
>>> allows us to save the overhead of loading up another "python"  
>>> process)
>>> * Reap all instances still in the "starting" state for more than X  
>>> seconds
>>> that have not explictly requested this functionality to be  
>>> disabled nor
>>> signaled via the dbus that they are still active
>>
>> 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.

> The problem I see is that both the available memory in the system and
> the consumed memory by a single activity are complex to measure and
> much more to anticipate, so we probably won't get good enough
> estimations to put in the activity.info.

And, for me at least, the two activities (often running by themselves)  
that are more likely to cause a memory lock-up are Browse and Read –  
and it's all down to the content complexity/zoom level they are trying  
to display. If you set some kind of memory limit per activity you'd be  
needing to frequently edit those settings to visit  some web sites, or  
view some pdfs.

Now I could see an argument that says, when launching any new  
activity, first check that at least ~10% of memory can be allocated***  
That would perhaps help in the use case where many activities are  
started but never stopped (finally ending in a lockup that requires a  
power off), while allowing some memory breathing space for the sugar  
shell UI to keep flowing.

*** seems tough to get right due to all the memory sharing that goes on.

Regards,
--Gary

> Regards,
>
> Tomeu
>
>> Just seems like we should be attacking the problem by attacking the  
>> problem.
>> Cheers,
>> Wade
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel