This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-25
Channels
- # aws (10)
- # babashka (4)
- # beginners (103)
- # calva (19)
- # chlorine-clover (2)
- # cider (10)
- # cljs-dev (23)
- # cljsrn (6)
- # clojure (145)
- # clojure-europe (17)
- # clojure-nl (1)
- # clojure-spec (11)
- # clojure-uk (4)
- # clojurescript (64)
- # conjure (11)
- # core-async (19)
- # cursive (38)
- # datomic (4)
- # duct (2)
- # fulcro (51)
- # helix (11)
- # joker (1)
- # kaocha (7)
- # leiningen (3)
- # malli (5)
- # meander (3)
- # off-topic (12)
- # pathom (17)
- # pedestal (2)
- # re-frame (27)
- # rum (11)
- # shadow-cljs (77)
- # xtdb (9)
- # yada (1)
Is it documented somewhere that the channel returned from a go block is closed after a take, or should this be obvious for a reason I'm missing?
(let [x (go 123)]
(go
(println "X" (<! x)) ;;123
(println "X2" (<! x)) ;;nil
))
the alternative would be a pending take that parks forever and can never be satisfied?
what about a channel you can put something else on later? (I realize this would only be usable if you keep a reference to the result of the go block which isn't how it's meant to be used)
you want to reuse the channel returned from a go block as a general purpose channel and put other things on it?
I have some api functions that look like this
(defn get-file [this path]
(go (->entry (<p! (.getFile gentry path gdir/Behavior.CREATE)))))
At first I took a final chan argument to put the result on but then I figured I could get away with just returning the go blockthen later when just messing with the repl I figured I might be able to re-use that chan instead of having to create one, to put subsequent results on
Really a go block doesn't return a channel, it returns a readport (a channel is a full duplex combination of a read and write port). A channel just happens to be the most convenient impl of a readport
Like basically this is what I was trying
(let [fch (get-file filesystem path)]
(go-loop []
(do-stuff-with-file (<! fch))
(recur)))
using the internal go block to represent the initial value but then reuse it to subsequently "Set" fileswhere is the channel returned from the go macro hobbled? it seems that it literally returns (chan 1)
You just have to imagine that using the writeport part of a channel returned by a go block is undefined behavior