This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-19
Channels
- # adventofcode (82)
- # beginners (70)
- # boot (34)
- # boot-dev (13)
- # cider (45)
- # clara (4)
- # cljs-dev (3)
- # cljsrn (2)
- # clojure (91)
- # clojure-art (8)
- # clojure-czech (1)
- # clojure-dusseldorf (3)
- # clojure-france (11)
- # clojure-germany (1)
- # clojure-greece (39)
- # clojure-hamburg (1)
- # clojure-italy (24)
- # clojure-norway (2)
- # clojure-spec (7)
- # clojure-uk (31)
- # clojurescript (56)
- # core-async (7)
- # cursive (8)
- # data-science (10)
- # datomic (41)
- # duct (7)
- # emacs (1)
- # events (1)
- # fulcro (83)
- # graphql (6)
- # klipse (1)
- # leiningen (28)
- # lumo (67)
- # off-topic (14)
- # om (9)
- # onyx (3)
- # perun (4)
- # re-frame (22)
- # reagent (11)
- # ring-swagger (2)
- # rum (1)
- # specter (46)
- # sql (13)
- # uncomplicate (17)
- # unrepl (114)
i'm trying to gracefully stop some code that's using mult/tap. i'm shutting down the producer that writes to the mult and waiting until all of the mult and tap buffers are empty. but that won't be enough if one of the tap consumers takes a bit of time to process the last item coming out of the tap. i started looking at keeping track of whether the consumers are processing an item or waiting for a new one. but i can't figure out a way keep track of that kind of state without a race condition. has anyone attempted something like this? i'm wondering if i should be using a part of core async other than mult/tap
@jjfine why not wait for the code containing the consumers of the taps to exit? eg. wait on the channel that go
returned
np - it takes a while for the natural / easy choice to be intuitive with core.async haha
but yeah, a good rule of thumb is that it’s easier to wait on a channel rather than a consumer, and you can always ensure that consumer closes a channel (in fact it is probably doing so already whether you think of it that way or not)