[Gc] explicit thread registration
hans.boehm at hp.com
Mon Dec 3 17:01:36 PST 2007
Have you looked at GC_register_my_thread and friends in gc7? You still have to bypass the macro definitions of thread creation primitives, which should probably be made easier. But otherwise it sounds to me like that's bascically what you want (except for the fact that it's not terribly well tested, and the code for retrieving the thread stack base just returns GC_UNIMPLEMENTED on some platforms).
GC_INIT() should register the thread it's called from,which may have to be the main thread.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of MenTaLguY
> Sent: Sunday, December 02, 2007 11:41 AM
> To: GC Mailing List
> Subject: [Gc] explicit thread registration
> 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 valgrind.
> 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
> 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).
More information about the Gc