[Haskell-cafe] Bug-free, leak-free, battle-tested library for broadcast channels?

[David Turner]

At a high level, it means it does what I think you're looking for: the
"read end" of the channel created there isn't connected to anything, so
there's no leak if there's no consumers. But duplicating it gives you a new
"read end" that yields values as you would expect.

Without going into too much detail about STM, everything runs in a
transaction, and `retry` means to roll back any changes within the
transaction and start again. An unconditional `retry` (including
unconditionally reading from a channel created with `newBroadcastTChan`) is
a deadlock and therefore probably a mistake. So don't do that!


On 25 Jan 2017 05:41, "Saurabh Nanda" <saurabhnanda at gmail.com> wrote:

The implementation in STM works well and certainly ticks the battle-tested
> box:
>
> https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control
> -Concurrent-STM-TChan.html#v:newBroadcastTChan
>


What does the following comment in the documentation really mean
(highlighted by >>><<<)?

"Create a write-only TChan
<https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#t:TChan>.
>>> More precisely, readTChan
<https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#v:readTChan>
 will retry
<https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Monad-STM.html#v:retry>
 even after items have been written to the channel.<<< The only way to read
a broadcast channel is to duplicate it with dupTChan
<https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#v:dupTChan>
."



-- Saurabh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170125/17d98838/attachment.html>