Proposal: Add tryReadChan to Chan

[Duncan Coutts]

On Sat, 2010-11-27 at 01:51 +0100, Mitar wrote:
> Hi!
> 
> Now that isEmptyChan is deprecated (#4154) it would be useful to add
> tryReadChan. It seems it is possible to define it so that it does not
> block like isEmptyChan. This is because semantics is a bit different:
> tryReadChan is allowed to return Nothing also when Chan is non-empty,
> but it would block. Contrary, isEmptyChan is expected that it would
> return False only if Chan is really empty.
> 
> I have defined also two new MVar functions which helped me
> implementing tryReadChan: tryReadMVar and tryModifyMVar. Probably it
> would be useful to make them public.
> 
> Please comment. I propose three weeks for discussion.

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.

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

Duncan