Proposal: Add tryReadChan to Chan

Neil Mitchell ndmitchell at
Sun Dec 12 22:28:19 CET 2010

>>>> 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?


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 - 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

More information about the Libraries mailing list