https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #23 from Tomash Brechko <[email protected]> --- 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. --
