[RFC] Fix PosixProcess by porting VMProcess from Classpath...

Wed Jul 14 19:44:00 GMT 2004

David Daney wrote:
>As you noted there are potential race conditions as there is no way to
>simultaneously unblock signals and wait for a process and the signal.
>>The answer is to send the signals in a loop until the forking thread
>leaves wait().
>>
Hmm, that doesn't sound very elegant :-) Note that sigwait() doesn't 
have the race problem because you block the signals from being received 
asynchronously - the signals are only consumed when you call sigwait().
>>As for what signal to use, anything should be ok provided we don't 
>>conflict with the GC's signals. posix-threads.cc defines a signal to 
>>implement interrupt(), perhaps we could use that. The sigwait() would 
>>handle both SIGCHLD and the "wake up" signal.
>>>>This ought to work so long as SIGCHLD is guaranteed to be delivered to 
>>the same thread which spawned the process? I'm not sure if this is 
>>guaranteed by the POSIX spec or not.
>>>>>>This is my problem with using the SIGCHLD/sigwait() combination. I
>don't know for sure how to guarantee that the signal is handled on the
>proper thread on all possible Posix platforms (not being a Posix expert
>and all). Does calling sigaction() from a thread guarantee that
>sigwait() on the same thread will wake up on that signal? I do not know.
>>
 From http://www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html
"At the time of generation, a determination is made whether the signal 
has been generated for the process or for a specific thread within the 
process. Signals which are generated by some action attributable to a 
particular thread, such as a hardware fault, are generated for the 
thread that caused the signal to be generated. Signals that are 
generated in association with a process ID or process group ID or an 
asynchronous event such as terminal activity are generated for the process."
So, it sounds like SIGCHLD should be sent to the process and not a 
specific thread - doh.
One way around this is to have all threads block SIGCHLD (easily done in 
the posix-threads.cc startup code). The only problem with this is the 
potential for a user's native application code, running in a non-libgcj 
thread, also wanting to handle SIGCHLD. In that case, their handler 
could end up getting our SIGCHLD signals.
Regards
Bryce