[reactive] Re: black hole detection and concurrency

Simon Marlow 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.

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 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?
> 
>     Cheers,
>            Simon
> 
> 



More information about the Glasgow-haskell-users mailing list