BlockedIndefinitelyOnMVar exception

[Simon Marlow]

On 04/07/10 10:30, Neil Mitchell wrote:
> Hi Simon,
>
>>> 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?
>
> Nothing to do with async exceptions. I found:
>
> http://hackage.haskell.org/trac/ghc/ticket/4154

Yup, that's a bug.  Not clear if it's fixable.

> http://hackage.haskell.org/trac/ghc/ticket/3527

That too.  A very similar bug in fact, if there is a fix it will 
probably fix both of them.  The problem is that readChan holds a lock on 
the read end of the Chan, so neither isEmptyChan nor unGetChan can work 
when a reader is blocked.

> Of course, there's also the async exceptions bug still around:
>
> http://hackage.haskell.org/trac/ghc/ticket/3160

Yes, that's a bug (though not in Chan).

> However, even after having a program with no async exceptions (I never
> used them), and eliminating unGetChan and isEmpyChan, I still got
> bugs. I have no proof they came from the Chan module, and no minimal
> test case was ever able to recreate them, but the same program with my
> own Chan implementation worked. My Chan had different properties (it
> queues items randomly) and a subset of the Chan functions, so it still
> doesn't prove any issue with Chan - but I am now sceptical.

It's surprising how difficult it is to get these MVar-based abstractions 
right.  Some thorough testing of Chan is probably in order.

Cheers,	
	Simon