Re: Emergency memory pool for Glib

Federico Mena Quintero wrote:

One important thing, especially for embedded devices, is to ensure that
GTK+ apps won't abort() when g_malloc() fails.

I've started a wiki page to discuss having an emergency memory pool:

[Robert O'Callahan says that Nokia has a patch to do something like
this... can we simply use it?]


After random lunchtime chatter with Owen, I'd think you want:

 - g_malloc blocks on OOM by default
- the system has a process which has all its memory preallocated/reserved; the purpose of this process is to show a "what should I kill?" kind of UI, or to just magically kill the right thing (though the kernel has struggled a lot with the "what to kill on OOM" question, it should be easier in userspace since we can know what's the X server, what's critical desktop processes, etc.)
 - (whether the preallocation is just careful coding in this "monitor
process" or a kernel thing sort of like the 5% disk reserved for superuser, I don't know)

Then if you run out of memory, most of the apps hang; the "oom user interaction" app does not and either figures out or asks the user what to do, then with memory pressure relieved the other apps can unblock and continue.

If you try to handle it app-by-app you'll get a dialog from every single app in a typical oom situation. Also the mem parachute would waste ram in every app, and if one app was leaking it wouldn't even do any good, or would only help briefly.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]