http://d.puremagic.com/issues/show_bug.cgi?id=5488
Summary: Spawned threads hang in a way that suggests allocation or gc issue Product: D Version: D2 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: adam_conner_...@yahoo.com --- Comment #0 from Adam Conner-Sax <adam_conner_...@yahoo.com> 2011-01-25 20:05:49 PST --- Created an attachment (id=882) code to demonstrate the issue described above The attached program hangs more often than not during the second set of spawns (using dmd 2.051 on OSX). The thread functions do nothing but allocate a large array and then exit. In one case the array is an Array!double (from std.container) and in the other it is a built-in double[]. In the second case, a large enough array will cause the program to hang. Sean Kelly has already done some investigating, quoting from his responses: 1) 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. 2) After some testing, it looks like I was right. I have a fix for this, but it's far from ideal (though the diff is small): require everything but thread_resumeAll to acquire two locks in sequence, while thread_resumeAll only acquires the second. I'll try to come up with something better. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------