[Gc] Fix for threaded gc on MacOSX

Andrew Begel abegel@eecs.berkeley.edu
Thu, 11 Dec 2003 03:27:08 -0800

On Dec 11, 2003, at 12:00 AM, Andrew Begel wrote:

> On the other hand, using the test application from test.c seems to 
> hang waiting on a semaphore. Apparently my changes break the 
> traditional way of using the GC by override pthread_create() and 
> stuff.

A bit more debugging shows that my solution is almost right. 
Apparently, you should not try to suspend an already suspended thread 
(in GC_stop_world(), nor should you then try to resume a thread (in 
GC_start_world()) that you didn't suspend. Unfortunately, there's no 
way to tell the difference between a thread that you suspended with 
thread_suspend() and a thread that was suspended by someone else. And 
without using the GC_threads data structure there's no place to store a 
boolean to record the original state of the thread.

So, I'll try to change things to use the GC_threads data structures 
(suitably redefined for Mach threads). So, when is it safe to call some 
analog of GC_new_thread() (e.g. as defined in pthread_support.c) from 
within GC_stop_world()? GC_new_thread() calls GC_INTERNAL_MALLOC(). 
Might that screw something up? I basically need a pointer to where I 
can set up the GC_threads data structure to reflect the current set of 
active threads that is safe to call right before an inevitable call to