I also have a package called KickChan that implements something similar; if a consumer gets too far behind the channel becomes stale and the consumer will need to reconnect. This can be useful if e.g. the consumer gets an initial state and the channel only communicates updates.

On 14:17, Thu, Jan 28, 2016 Noon Silk <noonslists@gmail.com> wrote:

I think you should be able to do this with the `pipes` and `pipes-concurrency` libraries, in particular have a look at: http://haddock.stackage.org/lts-5.0/pipes-concurrency-2.0.5/Pipes-Concurrent.html#v:newest

--
Noon

On Fri, Jan 29, 2016 at 7:30 AM, Mark Fine <mark.fine@gmail.com> wrote:
We're currently using a TMChan to broadcast from a single producer thread to many consumer threads. This works well! However, we're seeing issues with a fast producer and/or a slow consumer, with the channel growing unbounded. Fortunately, our producer-consumer communication is time-sensitive and tolerant of loss: we're ok with the producer always writing at the expense of dropping communication to a slow consumer.

A TMBChan provides a bounded channel (but no means to dupe/broadcast) where a writer will block once the channel fills up. In our use case, we'd like to continue writing to the channel but dropping off the end of the channel. Clojure's core-async module has some related concepts, in particular the notion of a sliding buffer that drops the oldest elements once full. Has anyone encountered something similar in working with channels and/or have any solutions? Thanks!

Mark

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--
Noon Silk, ن

https://silky.github.io/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe