BlockedIndefinitelyOnMVar exception

[Simon Marlow]

On 01/07/2010 21:10, Neil Mitchell wrote:
> Hi Simon,
>
> Thanks for the excellent information. I've now debugged my problem,
> and think I've got the last of the MVar blocking problems out.
>
>>> * How confident are people that this exception does really mean that
>>> it is in a blocked state? Is there any chance the error could be
>>> raised incorrectly?
>>
>> There have been one or two bugs in the past that could lead to this
>> exception being raised incorrectly, but I'm not aware of any right now.
>>   It's not inconceivable of course.
>
> I have no reason to think it's broken. I found at least 3 separate
> concurrency bugs in various parts (one added the day before, one over
> a year old, one of which had been introduced while trying to work
> around the MVar problem).
>
> My suspicion for the root cause of the problem is that Concurrent.Chan
> is incorrect. In the course of debugging this problem we found 2 bugs
> in Chan, and while I never tracked down any other bugs in Chan, I no
> longer trust it. By rewriting parts of the program, including avoiding
> Chan, the bugs disappeared.I don't think I'll be using Chan again
> until after someone has proven in correct.

Considering Chan is <150 lines of code and has been around for many 
years, that's amazing!  Did you report the bugs?  Is it anything to do 
with asynchronous exceptions?

You should have more luck with Control.Concurrent.STM.TChan, 
incedentally.  It's much easier to get right, and when we benchmarked 
it, performance was about the same (all those withMVar/modifyMVars in 
Chan are quite expensive), plus you get to compose it easily: reading 
from either of 2 TChans is trivial.

Cheers,
	Simon