This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-18
Channels
- # adventofcode (20)
- # aleph (25)
- # announcements (4)
- # babashka (117)
- # beginners (150)
- # calva (4)
- # cider (9)
- # clj-on-windows (2)
- # clojure (9)
- # clojure-europe (4)
- # clojure-italy (3)
- # clojuredesign-podcast (18)
- # clojurescript (16)
- # conjure (1)
- # core-async (35)
- # cursive (13)
- # datalevin (6)
- # datomic (6)
- # fulcro (8)
- # hyperfiddle (5)
- # malli (8)
- # nextjournal (4)
- # off-topic (51)
- # pathom (4)
- # reagent (21)
- # sci (14)
- # shadow-cljs (22)
- # specter (3)
- # testing (22)
- # tools-deps (8)
- # xtdb (7)
What's the reason reduce is implemented as a function in core.async and not by the reduce interface or protocol?
Jo I thought I can call deref
on a channel but I can't. didn't Rich mention this in a talk?
But deref shouldn't change the reference. You're just looking at it. Looking is free. Take mutates the channel
I see that makes sense. I wanted to use the timeout arg for deref. But I can do it with alts
and timeout
. Or use future I guess.
The use case is doing work with a timeout
I've had a week of "how do I-s" turning into "what are you trying to do" So, what are you trying to do? Are you already building something with core async?
I have events and like to handle them async with a timeout. Doesn't matter so much if 1 piece of work fails it's more important that it keeps handling incoming stuff. I'm using a library that puts the events on a channel so there is core.async there. It's something like 1/second
Even when you time something out, you can leak resources because you didn't cancel the process. You take stuff out of a channel, then process it with a timeout?
I believe this was talked about at some point long ago but I don't think it has ever been implemented/released
you need a few things. For each of those, implement a cancellation mechanism, you need it anyway to avoid resource leaks. Then you can implement a uniform interface which times the task out and cancels it
I've used that "pattern" when I need to keep processing things, and at the same time each event can have a timeout, retry, etc
like putting the channels returned by go
into a channel? What can I then do with that?
It really depends on the use case and the specifics 🙂 I can write a wall of text here but it might only make it more confusing; Just a tool to keep in mind that is available, which might not be obvious, aka the fact that you can put channels on channels
I'd like to pass a control channel that stops a go-loop when I put :stop, alternatively when I close the channel. What is the usual pattern? If I do <!
from the control channel it will park right? So is there always some alt
going on?
(a/go-loop []
(a/alt!
control :stop
(a/timeout 300) (do (prn "loop") (recur))))
(a/>!! control :stop)
doing this nowThen you should utilize the fact that taking from a closed channel returns nil. Instead of a signalling channel close the input
This lends itself to a very nice pattern of automatically cascading shutdown if you build everything with little workers
(loop []
(let [data (a/<!! event-ch)]
(when-not (= data :disconnect)
(recur))))
is it fine to have such a loop recuring forever when the channel closes or should it check nil?Yeah, if the loop becomes infinite I believe you'll hog a thread from the thread pool (not good)
(loop [] (let [a b] ... (recur)))
is not different to (loop [a b] ... (recur b))
. And of course there is go-loop