This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-22
Channels
- # babashka (2)
- # beginners (81)
- # calva (5)
- # chlorine-clover (3)
- # cider (1)
- # cljsjs (1)
- # cljsrn (24)
- # clojure (67)
- # clojure-europe (3)
- # clojurescript (37)
- # code-reviews (2)
- # conjure (12)
- # core-async (4)
- # datalog (1)
- # datomic (6)
- # emacs (2)
- # figwheel-main (1)
- # graalvm (12)
- # java (4)
- # kaocha (9)
- # meander (3)
- # other-lisps (1)
- # pathom (14)
- # re-frame (2)
- # sci (32)
- # shadow-cljs (77)
- # sql (88)
- # xtdb (54)
Is there a reason why a mult
waits for all taps to take a message rather than just put!
ing the value on each tap and having the receiver be responsible for keeping up? I think I’m missing something philosophically about this
Because ultimately every consumer must keep up with the producer anyway, but why would one prefer that a single lagging consumer would hold up every other one, rather than just having that single consumer have problems?
@jjttjj You can avoid holding up other consumers if you tap into a channel with an unblocking buffer. The channel/buffer decides what happens if the consumer can't keep up. Just put!
ing values into a full blocking buffer would eventually make the mult blow up, rather than the slow consumer.