Re: Emergency memory pool for Glib

[Owen Taylor <otaylor redhat com>]

On Thu, 2006-07-13 at 11:01 -0500, Federico Mena Quintero wrote:
> Hi,
> 
> 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:
> 
> 	http://live.gnome.org/GTK%2B/LowMemoryPool
> 
> [Robert O'Callahan says that Nokia has a patch to do something like
> this... can we simply use it?]

Hmm, I have to say that this plan just doesn't make much sense to me at
all. I'll respond here rather on the wiki, since I find wiki's a bit
useless for pro-con discussion.

 - Memory pressure is global to the system, not for a specific app.
   Keeping a useful sized emergency memory pool per-app is incredibly
   wasteful. 

   (Yes, the only-one app does represent some subset of the embedded
   device case, but certainly not all of it.)

 - Freeing caches is an important way of dealing with low-memory
   situations, and possibly more useful than a pre-reserved memory.

   Now, you can't usually immediately free caches in the *same*
   application, because of re-entrancy issues, but you can do so in
   other apps, again indicating that this can't be implemented
   right just inside GLib.

 - The example code of:
  
    foo = gtk_foo_new ();

    if (g_needed_emergency_memory_pool ()) {
        gtk_foo_free (foo);
        dialog_box ("out of memory");
    }

   Seems to poorly map onto typical cases of running out of memory
   (loading a very big document or web page), because it depends
   on the amount of excess memory being smaller than your emergency
   memory pool.

   An emergency memory pool is more useful for making sure that the
   system keeps operating as you are displaying a dialog to the user
 
To make things robust and sensible for the user, you really need 
sophisticated schemes that involve:

 - Detecting which application are likely causing problems
 - Pausing applications while displaying feedback to the user
 - Killing applications that repeatedly cause problems, if they
   aren't vital to the user.

Etc. It's a hard problem, but I really don't think some toy emergency 
memory pool in GLib is going to help things much. If someone wants
something like that, they can implement it themselves with existing
facilities in 5 minutes.

					Owen