Proposal: Add tryReadChan to Chan

[Antoine Latter]

All of this really feels like what STM is good at. It might help if you
explained why TChans are not well suited to your task.
On Nov 26, 2010 6:51 PM, "Mitar" <mmitar at gmail.com> 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 have also opened a ticket:
>
> http://hackage.haskell.org/trac/ghc/ticket/4535
>
> and attached a ptach there with working implementation. It would be
> useful to run it against some tests.
>
> (I am sorry that patch is not in darcs format.)
>
>
> Mitar
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20101130/d3a5b608/attachment-0001.htm>