On 01/07/2010 21:10, Neil Mitchell wrote:
Hi Simon,
Thanks for the excellent information. I've now debugged my problem, and think I've got the last of the MVar blocking problems out.
* How confident are people that this exception does really mean that it is in a blocked state? Is there any chance the error could be raised incorrectly?
There have been one or two bugs in the past that could lead to this exception being raised incorrectly, but I'm not aware of any right now. It's not inconceivable of course.
I have no reason to think it's broken. I found at least 3 separate concurrency bugs in various parts (one added the day before, one over a year old, one of which had been introduced while trying to work around the MVar problem).
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? You should have more luck with Control.Concurrent.STM.TChan, incedentally. It's much easier to get right, and when we benchmarked it, performance was about the same (all those withMVar/modifyMVars in Chan are quite expensive), plus you get to compose it easily: reading from either of 2 TChans is trivial. Cheers, Simon