[Gc] thread suspend on darwin

Andrew Begel abegel at eecs.berkeley.edu
Tue May 18 12:48:48 PDT 2004


Good catch about the race condition.

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 
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).

Think that should work?

Andrew

On May 18, 2004, at 11:06 AM, Paolo Molaro wrote:

> Running mono on MacOSX, sometimes we get a
> thread_info failed
> message and libgc calls abort ().
> It's mostly random, but in some setups it can be triggered pretty
> easily. Looking at the code, this happens in GC_suspend_thread_list()
> in darwin_stop_world.c. The function is called after task_threads()
> retrieves the list of threads in the process and thread_info() is 
> called
> for each thread. The syscall returns an error (MACH_SEND_INVALID_DEST):
> it may happen that the thread quit between task_threads() and
> thread_info(), I suppose. The same could happen before thread_suspend()
> is called later in the loop, so this kind of errors should likely be
> ignored. Comments?
>
> lupus
>
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list