Re: out-of-mem handler

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Tim,

> > The only reason I want a callback is to do this:
> >
> > while (TRUE)
> >  {
> >    gpointer p;
> >
> >    sleep();
> >
> >    p = g_malloc_try();
> >    if (p)
> >      return p;
> > }
> >
> > (perhaps with a max number of tries for safety)
> 
> would this be the callback itself?
> 
> if so, i'm not very fond of adding a g_malloc_failed() callback for this
> specific purpose (you'd need a similar thing for realloc as well). if
> that is really required, i'd rather have a pluggable table of
> malloc+realloc+free calls, that programs (ones that *really* need it)
> could plug into glib *before* doing any else stuff. (much like libc
> allowes "overloading" of its basic allocation functions.)

Letting realloc be overloaded seems silly as you simply can't know how much of
the old mem has to be copied over to the new position, because the old length
is unknown. Using the new length might lead to a segmentation fault. And
letting malloc be overloaded, but not realloc is also not very clever. Even
Xlib doesn't allow intercepting malloc, and after some doubt in the beginning
I believe they did that for a good reason.

> you are aware, that you need to do similar things at the malloc level
> as well then, to prevent it from failing in xlib etc., right?

Which isn't possible portable (You have to use deploy some ELF internals to
still use the real malloc inside your own malloc, which is turn is used by
Xlib)
 
I would propose adding the _try variants and leave the matter alone.

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   |