On Tue, Feb 24, 2009 at 03:38, Wade Brainerd <wad...@gmail.com> wrote: > On Mon, Feb 23, 2009 at 5:57 PM, Luke Faraone <l...@faraone.cc> wrote: >> >> On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche <c...@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. 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. Regards, Tomeu > Just seems like we should be attacking the problem by attacking the problem. > Cheers, > Wade > > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel