<div dir="auto">Looks good to me. In particular, creating things in one transaction and using them in another is normal for STM.<div dir="auto"><br></div><div dir="auto">If you're creating the channel in a transaction on its own you might prefer to call this:<br><div dir="auto"><br></div><div dir="auto"><a href="https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#v:newBroadcastTChanIO">https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html#v:newBroadcastTChanIO</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 Jan 2017 07:55, "Saurabh Nanda" <<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Am I using broadcastTChan & STM correctly here? <a href="https://gist.github.com/saurabhnanda/3cc39f1e0a646254dd8819b01cd04ac3" target="_blank">https://gist.github.com/<wbr>saurabhnanda/<wbr>3cc39f1e0a646254dd8819b01cd04a<wbr>c3</a> Is it acceptable to basically create a `broadcastTChan` and make it "escape" the STM monad?<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 3:45 PM, Merijn Verstraaten <span dir="ltr"><<a href="mailto:merijn@inconsistent.nl" target="_blank">merijn@inconsistent.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Merijn<br>
<div><div class="m_-324760225512316850h5"><br>
<br>
> On 23 Jan 2017, at 11:52, Saurabh Nanda <<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>> wrote:<br>
><br>
> (cross-posted from Reddit because I'm not sure of the audience overlap between haskell-cafe & reddit)<br>
><br>
> 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:<br>
><br>
> * <a href="http://hackage.haskell.org/package/split-channel" rel="noreferrer" target="_blank">http://hackage.haskell.org/pac<wbr>kage/split-channel</a><br>
> * <a href="https://hackage.haskell.org/package/broadcast-chan" rel="noreferrer" target="_blank">https://hackage.haskell.org/pa<wbr>ckage/broadcast-chan</a><br>
><br>
> But, I'm not sure if these are battle-tested. Any help would be appreciated.<br>
><br>
> -- Saurabh.<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-324760225512316850gmail_signature" data-smartmail="gmail_signature"><a href="http://www.saurabhnanda.com" target="_blank">http://www.saurabhnanda.com</a></div>
</div>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>