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