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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120628/24da9ab3/attachment.html>
