BlockedIndefinitelyOnMVar exception

[Simon Marlow]

On 04/07/2010 21:51, Neil Mitchell wrote:
>>> 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.
>
> I wrote my Chan around the abstraction:
>
> data Chan a = Chan (MVar (Either [a] [MVar a]))
>
> The Chan either has elements in it (Left), or has readers waiting for
> elements (Right). To get the fairness properties on Chan you might
> want to make these two lists Queue's, but I think the basic principle
> still works. By using this abstraction my Chan was a lot simpler. With
> this scheme implementing isEmpyChan or unGetChan would both work
> nicely. My Chan was not designed for performance. (In truth I replaced
> the Left with IntMap a, and inserted elements with a randomly chosen
> key, but the basic idea is the same.)

I like the idea.  But what happens if one of the blocked threads gets 
killed by a killThread (e.g. a timeout) while it is waiting?  Won't we 
still give it an element of the Chan sometime in the future?  Perhaps 
this doesn't happen in your scenario, but it seems to throw a spanner in 
the works for using this as a general-purpose implementation.

The STM version doesn't have this bug, of course :-)  But then, it 
doesn't have fairness either.

Cheers,
	Simon