[reactive] Re: black hole detection and concurrency
marlowsd at gmail.com
Wed Jan 7 10:22:47 EST 2009
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.
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 <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> 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?
More information about the Glasgow-haskell-users