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