Re: Proposal: g_set_out_of_mem_handler

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Havoc,

> 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.

Yes, but that wont work for programs, that use external libs with their own
memory allocation. and even gnome-session does use Xlib. 
 
> 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.

But a user can't program a reliable realloc-fallback, because he doesn't know
the original size and thus can't copy the right amount, all he can do is just
call the systems realloc, and do something before that (waiting, e.g.), but
most people would surely do something like
g_free(really_big_buffer_I_allocated_before) or even worse
g_chunk_free(something) and such won't work.
 
> 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.

Ok, I'm not sure about the programs stack, there might be some problems there,
but other than that my approach is guaranteed to work, if you use it right.

> 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).

This of course is important to have, I agree.

> So:
>  - allow setting a "try again" function with signature identical to
>    malloc/realloc

Not sensible, see above.

>  - 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

fork on out of mem? doesn't sound very useful.

>  - change the default handler to exit(1) instead of abort()
>  - add g_unchecked_malloc(), g_unchecked_realloc()

Yes.

And of course I know the problems that come with my solution (Yes, replacing
the standard malloc smells bad, but the glibc malloc can't be that bad, I have
no figures, however), and so all I say is:

either: Dont care about out-of-mem.
or:     Do it similiar to the way, I proposed.

Both solutions have their merrits. But in my eyes a callback in the out-of-mem
case is completly wrong, because realloc can't be handled and because
programmers will most likly do something inside this callback (like calling
Glib/GTK+ functions), that simply won't work. (OTOH out-of-mem will not happen
very often... But even then a message "out-of-mem" would be better than just a
program hang.)

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |