[Gc] RE: using threads that were not created by GC_pthread_create()
Thong (Tum) Nguyen
Fri, 25 Jul 2003 10:07:25 +1200
Hi here :),
I've been thinking about this very problem lately. How about adding
GC_thread_attach and GC_thread_detach to the API? The win32 threading
support already has these somewhat implemented.
All the best,
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> Behalf Of Boehm, Hans
> Sent: Friday, 25 July 2003 9:37 a.m.
> To: 'eric lindvall'
> Cc: Boehm, Hans; 'firstname.lastname@example.org'
> Subject: [Gc] RE: using threads that were not created by
> > From: eric lindvall [mailto:email@example.com]
> > I am looking to embed mono (as a module) in an application
> > that makes use of
> > pthreads for which I do not have the source.
> > I've been told that if I use pthreads, I need to include gc.h
> > to override
> > the standard pthread_create() which calls the boehm hooks
> > that are needed
> > for the GC to work.
> That is currently correct. You may be able to avoid it if threads
> pthread_create don't ever do anything with the garbage-collected heap.
> GC_pthread_create is needed to force thread startup in the GC, which
> the real thread start function. The fake startup function basically
> following to a table:
> 1) The thread id, so that it can be stopped during GC.
> 2) The cold stack end(s), so that the stack(s) can be scanned by the
> These updates should happen with proper collector synchronization,
> holding the GC lock.
> If thread-local allocation is enabled (it should normally be for
> multithreaded environments), it also initializes some thread-local
tables for that.
> > Unfortunatly, because I am only writing a module for this
> > application, I
> > cannot override the applications pthread_create(). Is there a
> > way that I
> > can call something thit will do all of the GC setup stuff on
> > a thread that
> > is already created (GC_thread_setup() or something similar)?
> > e.
> I think it would be tricky to do that without cooperation of the
> You can certainly get the thread id, and you might be able to get the
cold stack end,
> depending on your platform. But getting those in and out of the
thread table without
> introducing a race sounds quite tricky. By the time you get a thread
id into the
> it may have been reused for another thread with a different stack.
> allocation code would probably also have to be restructured or turned
> Even if the thread can cooperate, the code isn't currently structured
to make that
> easily possible. But I wouldn't be at all opposed to fixing that.
(It would have
> to cooperate to register itself, and to unregister itself on the way
> Depending on the definition of "module" and on your environment,
> sometimes is to play linker games to intercept pthread_create, e.g. to
> that defines pthread_create,
> and then uses dlopen and dlsym internally to call the pthread version.
(This is done
> the wrap.h header in
> 0.2.tar.gz ,
> among other places.) The collector will probably acquire built-in
support for doing
> of this shortly, at least on linux.
> Gc mailing list