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

Wed Jul 14 19:06:00 GMT 2004

Bryce McKinlay wrote:
> Andrew Haley wrote:
>>>>David Daney writes:
>>>>>Andrew Haley wrote:
>>>>>>>So, we wait either to be notified or until one second has passed.
>>>>That doesn't seem like such a great scheme, altho' it's better than
>>>>what we do at present. 
>>>>>>>>I suppose the right thing to do is call wait(2) instead of waiting on
>>>>workList -- when we add a process to that list we can send the
>>>>reaper/initiator thread a signal to wake it up.
>>>>>>>>>>That is exactly what I was/am thinking.
>>>>>>What signal to send to wake it up?
>>>>>>SIGHUP, some "real time" signal, something else?
>>>>Hmmm. Tricky. :-)
>>>>Maybe SIGALRM ? SIGPOLL?
>>>> Perhaps sigwait() should be used rather than wait(). With wait() and 
> signals, it may be tricky to avoid race conditions - what happens if the 
> thread is signaled (by another thread wanting to start a process), 
> immediately before entering the wait() call?

sigwait() waits for signals. What we want to wait for is both signals
and terminated processes, one way to do it is to use wait().
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().
>> 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.
David Daney