marlowsd at gmail.com
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