gcj crashes if a user-thread gives up its rights

Tue Dec 14 16:39:00 GMT 2004

Jost Boekemeier wrote:
>On Mon, 2004年12月13日 at 18:17, Bryce McKinlay wrote:
>>>>It would be interesting to know how these other VMs solved the issue. 
>>>>>>Mediator pattern. The mediator still runs with the appropriate
>privileges. I guess GCJ already has a mediator which iterates through
>the list of threads and stops each of them when the user-thread's GC
>wants to run. The only thing that seems to fail is the command that the
>user-thread's GC sends to the mediator.
>>In the current code, there isn't a separate "mediator" thread - any user 
thread which the GC happens to run in will try to call pthread_kill to 
suspend the other threads.
>>Is there is another IPC mechanism with the necessary semantics - ie able 
>>to suspend any thread at any time, asynchronously? 
>>>>>>I think this should not be necessary. The mediator waits for commands
>anyway, so a simple pipe would be sufficient. Even a condition variable
>will work. So we only have to change the pthread_kill() into a
>pthread_cond_signal()
>That wouldn't work, because pthread_cond_signal() won't interrupt a 
thread that isn't actually waiting on the right condition variable. 
You'd still have to either use pthread_kill() or have the compiler 
insert interrupt points at each basic block edge. The later would have a 
performance effect and would be tricky to implement in the presence of 
blocking IO, etc.
What may work, however, is instead of sending the pthread_kill's from 
whichever thread the GC happens to occur in, dedicate one, always 
privileged thread to sending the pthread_kill's and running the GC. 
Suspended threads could then enter a pthread_cond_wait() waiting for the 
restart signal from the collector thread.
Regards
Bryce