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

[Alexander Larsson <alla lysator liu se>]

On Wed, 4 Oct 2000, Sebastian Wilhelmi wrote:

> > Is any one interested? Any comments?
> 
> Yes: Don't do it.
> 
> What would you want to do with other malloc implementations?
> 
> 1) Use different allocation strategies, memory locations etc: That seems to
> be    a reasonable idea. However I doubt, that there are many applications for
>    that, so it might be just as good to simply link against your own versions
>    of malloc, free etc.
> 2) Implement an out-of-memory callback: What will happen? A g_list_.. function
>    will call g_malloc, no memory is available, the callback is called, your
>    code there decides to free a cache (being a GList), but the main GList   
>    mutex will be locked. Bummer. In general the internal state will not be
>    consistent during a call to malloc, so allowing other calls from there will
>    be a nightmare.
> 
> For a longer discussion on that topic, please have a look at 
> 
> http://mail.gnome.org/archives/gtk-devel-list/2000-February/msg00076.html

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.

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

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.

Ok. How about this:
* Add a vtable based malloc, realloc, try_alloc, try_realloc, free
  implementation to glib
* rip out dmalloc support (Borken anyay)
* rip out the memory profiler/checker (Can be done using a vtable)

And, optionally, if the maintainers think it's suitable:
* Add a memory pressure callback. With suitable comments in the code 
  explaining the problems this can cause if used improperly ("Here be
  dragons")
* Add cache flushers in glib and gtk that can be called when there is 
  memory pressure

/ Alex