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

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hej Alex

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

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