Adam Conner-Sax Wrote: > The attached code usually hangs (running on OSX, dmd 2.051). > > It uses spawn to create a new thread. All the thread does is create a large > array of doubles. In one case it uses the Array!double from std.container. In > the other case it uses the built in dynamic double[]. It declares the array, > sets the length, then sends a message to main saying it is finished and exits. > > The Array!double case always runs fine. The built-in dynamic array case > usually hangs, though not always in the same place. > > And the array has to be sufficiently big (in my case 200000 or bigger I think) > or the problem doesn't occur. > > I've no idea why. It took me a *long* time to find this since it manifested > as very mysterious hanging in a more complex piece of threaded code. Now I've > switched to using Array!double in my code and it all works fine.
This one is weird, and doesn't appear related to 4307. One of the threads (thread A) is in a GC collection and blocked trying to acquire the mutex protecting the global thread list within thread_resumeAll. Another thread (thread B) is also blocked trying to acquire this mutex for other reasons. My best guess is that pthread_mutex in OSX is trying to give ownership of the lock to thread B, and since thread B is suspended it effectively blocks thread A from acquiring it to resume execution after the GC cycle. Please submit a new issue for this. I suspect this is OSX-specific, since OSX doesn't use signaling to coordinate stop-the-world collections (signaling *should* prevent a thread from being suspended while waiting for a mutex, while the suspend mechanism in OSX doesn't seem to).
