https://issues.dlang.org/show_bug.cgi?id=15939
--- Comment #10 from Aleksei Preobrazhenskii <apreobrazhen...@gmail.com> --- (In reply to safety0ff.bugz from comment #9) > Could you run strace to get a log of the signal usage? I did it before to catch the deadlock, but I wasn't able to do that while strace was running. And, unfortunately, I don't have original code running in production anymore. > I'm wondering if there are any other signal handler invocations in the > "...application stack" part of your stack traces. No, there was no signal related code in hidden parts of stack trace. > I've seem a deadlock caused by an assert firing within the > thread_suspendHandler, which deadlocks on the GC lock. In my case that was a release build, so I assume no asserts. > What should happen in this case is since the signal is masked upon signal > handler invocation, the new suspend signal is marked as "pending" and run > once thread_suspendHandler returns and the signal is unblocked. Yeah, my reasoning was wrong. I did a quick test and saw that signals weren't delivered, apparently, I forgot that pthread_kill is asynchronous, so signals should've coalesced in my test. > Their queuing and ordering guarantees should be irrelevant due to > synchronization and signal masks. Ideally, yeah, but as I said, I just changed SIGUSR1/SIGUSR2 to SIGRTMIN/SIGRTMIN+1 and didn't see any deadlocks for a long time, and I saw them pretty consistently before. So, either "irrelevant" part is wrong, or there is something else which is different and relevant (and probably not documented) for real-time signals. The other explanation is that bug is still there and real-time signals just somehow reduced probability of it happening. Also, I have no other explanation why stack traces look like that, the simplest one is that signal wasn't delivered. --
