out-of-memory [was Re: glib CVS ?]

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> > Good there's something left to do for Gtk+ 3.0.
> 
> there's stuff to do for 3.0, but certainly not making
> all our functions return NULL suddenly (the vast majority
> of our API that returns newly created things, e.g. g_obejct_new()
> are guaranteed to never return NULL).

If only allowing g_object_new() to return NULL was the least of the
problems....  appended is a perhaps useful summary of the situation
that I wrote up in response to a query directed to me recently..

Trying to figure out what to do for things like OOM failures in signal
handlers is close to intractable. An interesting research problem
perhaps, but interesting research problems in 500,000 line codebases
aren't generally that interesting.

If you want reliable out-of-memory handling, you want a 
much simpler and less powerful toolkit. 

Regards,
                                        Owen

=====
glib-2.0 will provide two things to help here:

 - The ability to replace g_malloc and friends with your own 
   functions that can take action to try to free up memory
   on OOM.

 - g_try_malloc() that can be used when the caller wants to handle
   failure. For instance, GdkPixbuf uses g_try_malloc()
   in case it is fed a huge image.

But in general:

 - Allowing g_malloc() to fail would mean that virtually every
   interface in GLib/GTK+ could fail with out of memory.  We consider
   this something that would make the GLib/GTK+ interfaces far less
   useable.

   It's important to only have functions allowed to fail when the
   caller can reasonably be expected to handle the failure; making
   everything possibly fail will mean that people won't handle the
   errors they need to handle.

 - Recovering from OOM on a desktop system is not really
   practical. Most likely, other components of the users desktop will
   die and/or the machine will become unusuable before you have
   anything to do with it.

   On embedded systems, the tradeoff here may be different.  GLib is
   not really suitable for deeply embedded devices and certainly not
   for critical real-time situations.

Basically, if you want to recover from OOM, you need to make that a
system design goal, and you have to know what needs to happen if you
run out of memory at any one point and make sure that you stay in a
consistent state on failure.

This would be a huge job for something like GTK+ ... a simple call
like gtk_widget_show (toplevel) can trigger hundreds or thousands of
individual actions. If creating the X window for the 503 window failed
due to OOM, trying to back up and leave things as they were before the
gtk_widget_show() call would be, to say the least, challenging.

With the GLib-2.0 changes we've tried to address this issue 
as much as possible without causing ourselves nightmares.