out-of-memory [was Re: glib CVS ?]
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Johannes Stezenbach <js convergence de>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: out-of-memory [was Re: glib CVS ?]
- Date: 26 Nov 2001 09:47:03 -0500
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.
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
- 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
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.
] [Thread Prev