BlockedIndefinitelyOnMVar exception

Simon Marlow marlowsd at
Sun Jul 4 16:20:00 EDT 2010

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:

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


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:

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.


More information about the Glasgow-haskell-users mailing list