[Haskell-cafe] Bug-free, leak-free, battle-tested library for broadcast channels?
gregmainland at gmail.com
Wed Jan 25 03:15:27 UTC 2017
I'm not sure if it's exactly what you're looking for, but I've been using
zeromq for this for a long time
http://hackage.haskell.org/package/zeromq4-haskell. It's bindings to a C++
library, but that means that you can communicate with other languages which
also have bindings.
On Tue, Jan 24, 2017 at 2:18 AM Merijn Verstraaten <merijn at inconsistent.nl>
> 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
> 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.
> > 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
> > -- 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.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe