[Issue 4890] GC.collect() deadlocks multithreaded program.

[via Digitalmars-d-bugs]

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

--- Comment #23 from Tomash Brechko <tomash.brechko at gmail.com> ---
I think the order of events is such that pthread_create() is followed by
pthread_kill() from main thread before the new thread had any chance to run. 
In this case there are reports that the new thread may miss signals on Linux:
http://stackoverflow.com/questions/14827509/does-the-new-thread-exist-when-pthread-create-returns
.  I think POSIX intent is such that pthread_kill() should work once you have
thread ID, i.e. it's a bug with (some versions of) Linux kernel (maybe the
signal is first raised and then pending signals are cleared (per POSIX) for the
new thread when it starts, or the signal is not become pending as it is not
blocked, but is not delivered either because the thread is not really running
yet; though on my 3.15.10 pthread_kill() after pthread_create() always works in
C, and I don't have D compiler at the moment to check if I'm still able to
reproduce original problem).  OTOH issue 10351 is marked as duplicate, but it's
not clear if the threads involved there are newly created.

On a side note, in thread_entryPoint() there's a place:

 // NOTE: isRunning should be set to false after the thread is
 // removed or a double-removal could occur between this
 // function and thread_suspendAll.
 Thread.remove( obj );
 obj.m_isRunning = false;

Note that if thread_suspendAll() is called after remove() but before assignment
you still will have double removal.  This shouldn't relate to bug in question
however.

--