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

[David Turner]

On an unrelated note, are you sure about using `getCurrentTime` to measure
the start and end times of your process? If you want to report on the
duration of the process, it can be better to use the monotonic clock from
here:

https://hackage.haskell.org/package/clock-0.7.2/docs/System-Clock.html

The trouble with the real-time clock is that it can change discontinuously,
even backwards, and it is hard to account for things like leap seconds with
it, so durations calculated by subtracting two UTCTimes are a little
unreliable.

OTOH you might well want to know the real start and end times of your
process instead/as well - it depends on your application.

Hope that helps,

David


On 25 Jan 2017 08:19, "David Turner" <dct25-561bs at mythic-beasts.com> wrote:

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/b37bb0bd/attachment.html>