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

[Saurabh Nanda]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170125/8f2ba46b/attachment.html>