[Gc] explicit thread registration
mental at rydia.net
Sun Dec 2 11:40:56 PST 2007
We've been successfully using libgc in Inkscape for a while now, but
we're increasingly having issues with incompatibilities with libraries
with worker threads for callbacks, and with debugging tools like
All of the incompatibilities stem from the methods which libgc uses to
automatically establish the base address of the stack and find new
threads. I think all that is required is an additional runtime "mode"
of libgc which turns off all of the automatic thread/stack registration
logic, and the addition of a call something like:
GC_API void GC_register_thread GC_PROTO((GC_PTR));
The call would register the current thread with libgc (if it's not been
registered already), with the provided pointer being the base address to
use for the stack (typically the address of a local variable). I think
the call should be idempotent except that an "earlier" base address will
replace a "later" one.
Threads could be automatically unregistered using the platform's
mechanism for destroying thread-local data on thread exit, though it
might make sense to also provide a GC_unregister_thread.
Now, one thing I'm concerned about how this should interact with
GC_INIT(). Would GC_INIT be universally safe to call without any
threads registered? Are there any other difficulties with this idea?
 We mostly need valgrind for its non-leak-checking features (although
a non-trivial portion of Inkscape does still use the system malloc).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20071202/7686fcfc/attachment.pgp
More information about the Gc