[Issue 15939] GC.collect causes deadlock in multi-threaded environment

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #10 from Aleksei Preobrazhenskii <apreobrazhensky at 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.

--