Hello, all:
I have a problem want to discus with you, Chris someone should be the right person.
In llvm-3.1.src/lib/support/unix/Signals.inc, in SignalHandler, we have:
static RETSIGTYPE SignalHandler(int Sig) {
…
SignalsMutex.acquire();
RemoveFilesToRemove();
…
}
We can also find following code snippet in the same file:
void llvm::sys::RunInterruptHandlers() {
SignalsMutex.acquire();
RemoveFilesToRemove();
SignalsMutex.release();
}
Similarly, there are SetInterruptFunction, RemoveFileOnSignal, DontRemoveFileOnSignal
I am afraid there is deadlock risk if llvm running in multithread mode, the case it is designed to safeguard.
Suppose, say when some thread runs into RunInterruptHandlers and acquire the Mutex, then it is preemptied by scheduler, and before it is reselected by scheduler, one signal is dispatched to it. Then just before the thread resuming at the end of schdeuling, the kernel will invoke SignalHandler to handle the signal, but may deadlock at mutex acquire (as kernel now is conditionally preemptied).
Maybe we can trylock (instead of lock) at the beginning of SignalHandler (the locking period should not be a concern as we running in the kernel now), if try fails, redispatch the signal and exits (try again in next time enter in); otherwise go ahead as usual.
Best Regards
Hui Wu