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

[Alexander Larsson <alla lysator liu se>]

On Mon, 9 Oct 2000, Sebastian Wilhelmi wrote:

> Hi Tim,
> 
> > > Here is a patch that adds a vtable to g_malloc, g_malloc0, g_realloc and
> > > g_free. It also adds g_try_malloc and g_try_realloc (not guaranteed to
> > > return non-NULL).
> > 
> > great, this is pretty much what i had in mind.
> > as you've probably seen in this thread and can be proven from earlier
> > threads on malloc virtualization/callbacks on this thread, it's close
> > to impossible to reach complete consensus on how out-of-mem situations
> > should be handled.
> > that's pretty much why i decided that for glib we'll go with a vtable
> > such as yours and let the masochists deal with the internals if they
> > really have to ;)
> 
> Ok, it seems, such thing can't be avoided any longer ;-), so let's at least
> make it sensible.

I agree.
 
> > struct _GMemVTable
> 
> We might want to call it GMemFunctions just like the GThreadFunctions. Just
> for more consitency.

I agree. Mine was GAllocFunctions, but GMemFunctions is actually better,
so its not mixed up with g_allocator.
 
> > is what the API should be limited to.
> > g_mem_set_vtable() has to be documented to only be callable
> > _prior_ to any other glib function, 
> 
> Which is not always possible (Think static C++-objects with constructore
> calling glib-functions.)

But it is possible (at no extra cost) to guarantee that the vtable-setter
function fails (with a warning) if g_malloc has been called before the
vtable is set. This would at least get rid of the spurious errors can
happen if the allocators are mixed up.
 
> > and it should puke if any
> > GMemVTable's mandatory parts aren't provided. *malloc0 can be
> > implemented in terms of *malloc + memset which is why it's optional.
> 
> > (*malloc)       GLib bails out if this returns NULL
> > (*realloc)      GLib bails out if this returns NULL
> > (*try_malloc)   GLib passes on the returned NULL
> > (*try_realloc)  GLib passes on the returned NULL
> > (*free)         always succeeds
> > (*malloc0)      same as (*malloc)
> > 
> > your memory pressure callback would be called from *malloc or *realloc
> > if they returned NULL, and if there's something that could be done about
> > it, the user can do that from his implementations of these functions (he
> > may have his own callback implementation there).
> > on the glib side, lets just keep things simple and virtualized so it's
> > tweakable if required.
> > 
> > notes on your implementation, g_malloc() and friends still have to be
> > real GLib functions to enforce guarrantees we make on the API.
> 
> 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.

/ Alex