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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
