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

[Sebastian Wilhelmi <wilhelmi ira uka de>]

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.

> struct _GMemVTable

We might want to call it GMemFunctions just like the GThreadFunctions. Just
for more consitency.

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

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

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   |