Re: Proposal: g_set_out_of_mem_handler

[Havoc Pennington <hp redhat com>]

Hi,

Much more useful than the "memory parachute" approach I think is the
"sleep for a while and then try again" approach - this is useful in
gnome-session, for example, because if the next program to try to alloc
memory is going to die, you want it to be any program _except_
gnome-session that ends up dying to free RAM.

You can get this functionality with just the trivial
set-out-of-mem-handler solution with no complicated tricks. I guess you
need realloc()- and malloc()-equivalent fallback functions but that's all.

I'm dubious about encouraging crazy memory parachute stuff, because it is
never even close to guaranteed to work, and the whole point of it is that
you need your app to be guaranteed to work. So if it can't be done with a
simple hack, I don't see it as worth the complexity/bloat.

Another simple thing that helps with the problem is to provide a
g_unchecked_malloc() routine that will return NULL instead of aborting.
Then if people are allocing a big hunk o' RAM (say an image) they can use
this to get the error checking, but still use g_free() (right now
gdk-pixbuf for example uses malloc() here, but it's annoying because you
have to remember to free() that chunk).

Also (I think Owen pointed this out), the default error handler shouldn't
dump core (is the backtrace useful here? not likely). Also, you could let
people set this error handler (called after the "fallback" function).

So:
 - allow setting a "try again" function with signature identical to 
   malloc/realloc
 - allow replacing the default error handler with some other action,
   like a custom message or some other kind of cleanup; people
   could even do a fork() and exec a gnome_segv type of dialog
   probably
 - change the default handler to exit(1) instead of abort()
 - add g_unchecked_malloc(), g_unchecked_realloc()

that's really simple and trivial and solves most of the problem...

Havoc