[Gc] Fix for threaded gc on MacOSX

Andrew Begel abegel@eecs.berkeley.edu
Thu Dec 11 19:16:20 PST 2003

On Dec 11, 2003, at 6:40 AM, Brian Alliet wrote:
> I think we can probably fix the problem where the gc can't be 
> initialized
> from a non-main thread without changing the stopping code so much. I 
> don't
> think using mach's task_threads really buys us much. The GC needs the
> GC_thread bookkeeping information for more than just stopping threads 
> so
> thats going to have to stick around regardless of how we're stopping 
> the
> threads.

And for applications that use NSThreads? As far as I can tell, there's 
no documentation that NSThreads are implemented using pthreads. Nor 
does this help me (it's important to be selfish sometimes), since I 
can't control pthread_create() when my BW-GC-using library is loaded by 
Java (its threads, NSThread or pthread, have already been created using 
the non-overridden thread creation routines).

> If you have threads that aren't using the GC's pthread_create function
> then there would be a race condition when you call task_threads. 
> Another
> thread could potentially be created after this call. However, as long 
> as
> all threads using the GC were created using the GC's pthread_create 
> this
> should work because GC_pthread_create acquires the lock.

You are right about the race condition with task_threads(). Perhaps 
it's possible to use task_set_emulation() to override thread_create() 
and thread_create_running() and cause them to block while we're 
suspending threads in GC_stop_world()?

> FindTopOfStack kind of makes me nervous too. As long as the compiler
> doesn't do anything strange it should work fine though.

It hasn't crashed anything yet. Though I'm playing with 'accepted' 
languages like C, C++ and Java that all come from Apple and play by 
Apple's ABI rules. YMMV.


More information about the Gc mailing list