On Wed, Jan 7, 2009 at 7:22 AM, Simon Marlow <marlowsd@gmail.com> 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 <marlowsd@gmail.com <mailto:marlowsd@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?

Cheers,
Simon