Re: [glib] malloc and bdwgc

[Thomas Martitz <kugel rockbox org>]

Am 12.01.2016 um 04:03 schrieb 张海:
> 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?

This is tricky. If you can't make GC_malloc() call __libc_malloc 
instead, you can only try to detect recursion. Either with some 
unwinding library or with a static recursion counter.

A recursion counter is subject to race conditions in a multi thread 
program, though, so you might need to use thread local storage (see 
pthread_key_create(), pthread_setspecific(), pthread_getspecific(); gcc 
suppots tls with __thread decorator, but beware that this automatism 
might result in malloc() calls) or ensure coherency through locks.

It's unfortunate that glib doesn't support your use case anymore. It 
seems to follow the glib/gtk theme of breaking non-gnome applications by 
dropping long-existing APIs out of the blue (/rant).

Best regards.