Proposal: Add tryReadChan to Chan

[Neil Mitchell]

>>>> 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?
>>>
>>> http://hackage.haskell.org/trac/ghc/ticket/4535#comment:2
>>
>> 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?
>
> http://hackage.haskell.org/trac/ghc/ticket/4154

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