[Gc] thread suspend on darwin

Andrew Begel abegel at eecs.berkeley.edu
Wed May 19 13:58:29 PDT 2004

Your patch seems to work fine for my GC-enabled application on my 
MacOSX 10.3.3 box.  If it works to get rid of your bugs, then I think 
it's ok to incorporate into the trunk.


On May 19, 2004, at 8:56 AM, Paolo Molaro wrote:

> On 05/18/04 Andrew Begel wrote:
>> You can't just ignore the failed thread_info() and thread_suspend()
>> calls, because in GC_start_world(), you'll encounter them again trying
>> to wake up dead threads. It might be better to add a field to struct
> When I tried it, just replacing the abort with a continue was enough
> (since GC_mach_threads_count is not increased that way).
>> GC_mach_thread to record if a thread died in the middle of trying to
>> suspend it (it can't die during wake up, since it's suspended and not
>> running), and not wake it up. If memory is at a premium, we could
>> easily overload the GC_mach_thread.already_suspended boolean, since 
>> the
>> logic is the same (if a thread was already suspended when we called
>> GC_stop_world(), then GC_start_world() should not try to start it).
> The attached patch does this and it seems to work just as well.
> The patch doesn't ignore an error on resume and it ignores any error
> from the syscall: looking at the header file there are several error
> codes that could be returned so checking just for 
> seems more fragile to me.
> lupus
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> <gc.patch>

More information about the Gc mailing list