Hi Tomeu, in general, I think we are saying the same thing :-)
With one exception -- OOM happens because memory is allocated. Sugar-shell cannot (and I say should not) try to arbitrage in there. If we try to do it from sugar-shell, all we can do is poll. If we poll infrequently, we won't catch them, if we poll frequently, we'll burn battery, introduce random lags... and still not catch many. When the shell is in the bg, IMHO it should be as "dormant" as possible. There are some opportunities for the shell to step-in in a friendly manner -- activity open, activity switch, I propose that those events are a natural place; and if a delay happens there is not very disruptive for users. Between those events checking for low-mem and seeding the OOM killer to catch runaways, we'll have something. I don't know of there's a way to ask the OOM killer to run a process on a lower threshold -- or send a signal to an existing one, that'd make more sense :-) . If it does, we could have a tight C process listening there of OOM "warnings" and sending friendly "close now plz" dbus signals. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
