Re: [patch] calling g_malloc & co via a vtable
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: Alexander Larsson <alla lysator liu se>, Gtk Development List <gtk-devel-list gnome org>
- Subject: Re: [patch] calling g_malloc & co via a vtable
- Date: Wed, 04 Oct 2000 13:16:31 +0200
Hej Alexander,
> 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).
>
> 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
> The memory check and profiling has got a lot of ifdefs in it. Since they
> are now in a vtable you could actually compile them in all the time. Or
> just rip them out and let the application do such stuff by themselves.
For that reason admittedly such a vector could be used, but I wouldn't like
that being exported.
> One thing that i'd like to add, which is pretty usefull in embedded
> systems is a memory pressure callback. It would be called when
> malloc() fails to let the developer try to free some memory (flushing
> caches etc). What do you think of this? It could be done by the user using
> a custom GAllocFunctions, but then Gtk+ and Glib couldn't use it.
Nono, I knew, that would finally be the reason for the callback... Don't.
BTW.: How do you implement realloc without knowing the previous allocated
size?
Hej då
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 |
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]