On Jan 11, 2016 7:03 PM, "张海" <dreaming in code zh gmail com> wrote:
>
> Yes, but the point of my previous email is that the third-party GC_malloc() might eventually call malloc() itself, and by defining a malloc() in my program, GC_malloc() will again call into my malloc() and then GC_malloc() until stack overflow. Do you think this will happen?One possible solution is to use something like libunwind to look at the call stack. If your malloc detects it is called recursively, call __libc_malloc instead of GC_malloc.
> Meanwhile since glib provides basic data structures for developers to build their own data structure upon, and developers should be able to decide which allocator their own data structure should use, I still think a GMemVTable should be conceptually necessary. Is there anything that prevents this from being implemented, for example with a g_mem_vtable_init_hook() function? (Are weak symbols possible to be portable? Or if not, missing such feature will still prevent many applications from migrating to the new version of glib.)
It looks like almost nobody used this feature, and it had a performance impact, so it was removed.