As part of forkProcess we discard all tasks except the one task that remains. As part of this we call freeTask, and freeTask in turn calls closeCondition and closeMutex, which are very thin wrappers around pthread_cond_destroy and phread_mutex_destroy. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently.

For the global mutex we don't attempt to call pthread_cond_destroy or pthread_mutex_destroy, but instead re-initialize them. The patch

https://phabricator.haskell.org/D59

does precisely that for the condition variables and mutexes associated with tasks. This is somewhat or a long way around, because we will then subsequently still call pthread_..._destroy, but it means that we don't have to mess with freeTask.