Hi Simon, That's great news. Please let me know when there's a build I can grab, and I'll try it out.
Regards, - Conal On Wed, Jan 7, 2009 at 7:22 AM, Simon Marlow <[email protected]> wrote: > The bugs that we have identified result in deadlocks - the runtime doesn't > notice that a thread blocked in throwTo can continue. I can't think of a > way that this could lead to bogus <<loop>>, but I suppose I wouldn't be too > surprised if it were possible. > > The best way forward is for you to test out a snapshot once these patches > have made it into a build. Does that sound reasonable? I've been running > your TestRace program for quite a while on 4 processors without any hangs > now. > > Cheers, > Simon > > Conal Elliott wrote: > >> I don't know if the bug would explain <<loop>>. My guess is that the >> black-hole-detection code is incorrectly concluding there is a black hole >> because a thunk was marked as in the process of being evaluated, then the >> evaluating thread is killed without unmarking the thunk, and then another >> thread needs the whnf. This is a fairly naive guess. I don't know this >> machinery well enough to have confidence. >> >> What do you think? >> >> - Conal >> >> On Tue, Jan 6, 2009 at 6:27 AM, Simon Marlow <[email protected] <mailto: >> [email protected]>> wrote: >> >> Conal Elliott wrote: >> >> Indeed -- many thanks to Bertram, Sterling, Peter & others for >> the help! I think getting this bug fixed will solve Reactive's >> mysterious bugs and unblock its progress. >> >> >> Ok, we can fix the fairly simple bug that a thread created in >> blocked mode blocks throwTos after the thread has finished. But I'm >> slightly suspicious of the <<loop>> results you were getting - does >> this bug explain those too? >> >> Cheers, >> Simon >> >> >> >
_______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
