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

[David Turner]

Looks good to me. In particular, creating things in one transaction and
using them in another is normal for STM.

If you're creating the channel in a transaction on its own you might prefer
to call this:

https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#v:newBroadcastTChanIO

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

> Am I using broadcastTChan & STM correctly here? https://gist.github.com/
> saurabhnanda/3cc39f1e0a646254dd8819b01cd04ac3 Is it acceptable to
> basically create a `broadcastTChan` and make it "escape" the STM monad?
>
>
>
> On Tue, Jan 24, 2017 at 3:45 PM, Merijn Verstraaten <
> merijn at inconsistent.nl> wrote:
>
>> I don't know about split-channel, which seems to try and have a lot of
>> functionality, but broadcast-chan is literally (and I mean the "copy+paste"
>> kind of literally) the exact same implementation as Control.Concurrent.Chan.
>>
>> The only difference is that, with Control.Concurrent.Chan each Chan
>> always has access to both the read and write end of the Chan. This read end
>> will keep data inside that Chan alive (and thus in memory!) indefinitely,
>> if no one reads from that Chan. If you use dupChan this will create a new
>> read end that tracks data in the Chan separately from the original one.
>>
>> This means that if you have a worker that only ever writes into a Chan,
>> this read end is basically keeping everything you write into the Chan alive
>> forever.
>>
>> broadcast-chan does the exact same thing as 'newBroadcastTChan' from
>> Control.Concurrent.STM.TChan, that is your original Chan contains a "write"
>> end only, and not a read end, the end result of that is: If you create a
>> new write channel any message you write into it will, if there are no
>> listeners, be immediately dropped and GCed. If you create "read" ends, then
>> each read end will receive every message written into the write end, as
>> long as the read end is active. So if you create 5 workers with a new read
>> end each, then every message written after those have been created will be
>> seen by all workers.
>>
>> So, if your problem is "I want to broadcast messages, but messages that
>> are sent when there are no listeners should be dropped and forgotten", then
>> use broadcast-chan.
>>
>> The package itself isn't "battle-tested", but since it's basically a
>> copy+paste of Control.Concurrent.Chan with a trivial wrapper, I feel fairly
>> confident that it doesn't have any major problems.
>>
>> Cheers,
>> Merijn
>>
>>
>> > On 23 Jan 2017, at 11:52, Saurabh Nanda <saurabhnanda at gmail.com> wrote:
>> >
>> > (cross-posted from Reddit because I'm not sure of the audience overlap
>> between haskell-cafe & reddit)
>> >
>> > I want to broadcast some instrumentation data from deep within my
>> Haskell app. This data will have listeners in some environments (say,
>> debug), but not others (say, production). Which library should I be using?
>> A little searching threw two possible candidates:
>> >
>> > * http://hackage.haskell.org/package/split-channel
>> > * https://hackage.haskell.org/package/broadcast-chan
>> >
>> > But, I'm not sure if these are battle-tested. Any help would be
>> appreciated.
>> >
>> > -- Saurabh.
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>>
>
>
> --
> http://www.saurabhnanda.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170125/aa76d4d0/attachment.html>