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

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hej Alexander,

> Ok, I can understand someone thinking that handling an out-of-memory
> condition callback from malloc is hard. You have to make sure you don't
> call any function that might allocate memory (try_malloc is ok though) and
> you have to take care not to deadlock. Things are quite limited, but
> it's not impossible to free some memory.

yes, and that means for example: You can not call most of the _free functions
of GLib, as they often lock a mutex, that is also locked around some
allocations.

> In systems that just *can't* stop working (embedded systems or
> critical components like gnome-session) this kind of thing is very
> important, and i think glib should support it in some way. C++ for
> instance has this kind of deal (set_new_handler).

That doesn't make it a good idea (just for the record: I like and use C++)
 
> Given a vtable based allocator this could be done externally though, so
> I'm not 100% sure glib needs this.
> 
> > BTW.: How do you implement realloc without knowing the previous allocated
> > size?
> 
> Eh? The way you always did it. The same way free is implemented. The
> allocator must have inner knowledge about the size of memory blocks.

See my other reply.
 
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   |