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

Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean@invisibleduck.org

--- Comment #22 from Sean Kelly <sean@invisibleduck.org> ---
I'm unclear why you're calling thread_suspendAll/thread_resumeAll in those examples.  These routines are for the GC to coordinate collections and have very strict requirements imposed on their use, fairly similar to those for code within signal handlers.  When all threads are suspended, you can't do anything that might block (such as call malloc) or the app could deadlock.  Was this simply for illustrative purposes?

Upon further reading, it seems like the problem was that the folks working on dynamic library support weren't aware of this limitation.  Yes, the thread-GC interface is very race-prone, and heavily commented as a result.  If someone could come up with an alternative to using signals for coordinating collections on linux, that would be awesome.

--

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

--- Comment #23 from github-bugzilla@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/e8f6550709c42ef5f62d56bd92a36466fc3c3e3a don't suspend threads before Thread.setThis is called

- guarantees that Thread.getThis is non-null in signal handler - allows to use TLS for Thread.sm_thread (Issue 11981)

--

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

--- Comment #24 from github-bugzilla@puremagic.com ---
Commit pushed to 2.067 at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/e8f6550709c42ef5f62d56bd92a36466fc3c3e3a don't suspend threads before Thread.setThis is called

--