I've not looked at it in detail, I just wanted to mention that I would be nervous about accepting this unless someone like Simon Marlow reads it over and decides the locking works.
I think he did?
Oh sorry. When I said I've not looked at it in detail, that included not reading the ticket, just your email :-)
This sort of stuff is notoriously subtle, for example Neil Mitchell is convinced we have a deadlock bug in the current Chan code (without using isEmptyChan), but he cannot pin it down (but using his own trivial Chan impl cures the deadlock).
Can you give me a link to a test code which fails with current implementation of Chan? Or does this problems with pinning it down means that there wasn't yet simple code which would show the problem?
You can ask him, since it was some time ago when he mentioned it, but I think narrowing it down was part of the problem.
Was it this?
No. I never managed to narrow it down enough to a test case that showed Chan was at fault, but I'm still "slightly wary" of it - eliminating Chan made the bug go away, but that's hardly conclusive. It's possible what I was actually seeing was a runtime bug instead (could be http://hackage.haskell.org/trac/ghc/ticket/4835 - that bug was narrowed down from something with similar characteristics to the program which was having problems). What I did learn is that MVars (while great) are too complex for highly fallible humans, and I want mathematical proofs and extensive randomized testing on all concurrency primitives. Thanks, Neil