Re: [patch] calling g_malloc & co via a vtable

[Alexander Larsson <alla lysator liu se>]

On Mon, 9 Oct 2000, Sebastian Wilhelmi wrote:

> > > Hmmm. So the difference between try_alloc and alloc is, that alloc should
> > > try to do what it can to get memory, while try_alloc might after the first
> > > failed try to get the mem return NULL. That difference really doesn't seem
> > > to justify this "bloated" interface. Why not simply providing malloc,
> > > realloc, free and malloc0 (which OTOH seems like a good idea) and
> > > diverting it one level above into the try and the other variants.
> > 
> > No, you must be able to differentiate in your callback between malloc and
> > try_malloc. Otherwise you can't try to free memory for failed malloc
> > but not for failed try_malloc in your replacement allocator.
> > 
> > You should be able to safely use g_try_malloc in a failed g_malloc
> > callback.
> 
> But there are no callbacks. So if you want callbacks, you have to program them
> yourself and then you are free to add a try_malloc function to aid that
> callback. But I think, _GLib_ doesn't need both functions (What I mean is:
> GLib needs to have g_try_alloc, but not try_malloc in GMemFunctions)

Lets say there is only malloc in GMemFunctions and I implement a custom
malloc that calls a callback on failure. If I then call g_try_malloc() and
if fails it will be the custom handler that fails, and it will call the
callback. 

The idea would be that g_try_alloc() should not do that, and that is
impossible to implement without separating malloc and try_malloc in the
table (or adding a boolean to malloc, but that would prevent having the
standard malloc in the vtable and thus lead to extra levels of 
indirections).

/ Alex