This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # babashka (2)
- # beginners (112)
- # calva (29)
- # cider (33)
- # clj-kondo (41)
- # cljdoc (10)
- # cljs-dev (2)
- # clojure (72)
- # clojure-berlin (3)
- # clojure-europe (10)
- # clojure-italy (6)
- # clojure-nl (15)
- # clojure-spec (5)
- # clojure-uk (40)
- # clojurescript (1)
- # clr (6)
- # community-development (6)
- # core-async (21)
- # cursive (42)
- # datascript (12)
- # duct (6)
- # flambo (1)
- # fulcro (50)
- # jobs (1)
- # leiningen (3)
- # off-topic (16)
- # re-frame (6)
- # reagent (23)
- # reitit (7)
- # ring-swagger (14)
- # shadow-cljs (35)
- # tools-deps (39)
- # vim (12)
Am I correct in that the usage of
Thread/sleep is not recommended as in example from Brave clojure? https://www.braveclojure.com/core-async/#alts__
Should one use
(defn upload [headshot c] (go (Thread/sleep (rand 100)) (>! c headshot)))
>!cannot be used outside of
And btw. why does this keep printing different channel "strings" (I expected the same channels/pictures would lead to the same .toString representation):
(let [c1 (a/chan) c2 (a/chan) c3 (a/chan)] (upload "serious.jpg" c1) (upload "fun.jpg" c2) (upload "sassy.jpg" c3) (let [[headshot channel] (a/alts!! [c1 c2 c3])] (printf "Sending headshot notification for %s (%s)\n" headshot channel))) Sending headshot notification for fun.jpg ([email protected]) Sending headshot notification for fun.jpg ([email protected]) Sending headshot notification for fun.jpg ([email protected]) Sending headshot notification for fun.jpg ([email protected]) Sending headshot notification for serious.jpg ([email protected]) Sending headshot notification for serious.jpg ([email protected])
append-to-file inside the
go block (https://www.braveclojure.com/core-async/#Queues) also doesn't look like the best approach
another question: how do people monitor core.async channels in practice? I couldn't find much about this stuff, only this http://tgk.github.io/2013/10/inspect-core-async-channels.html
The more appropriate thing to do in that snippet would be
(a/timeout (rand 100)) rather than the sleep
Yes, thanks, also found that option. In general, it seems that blocking calls are tricky. Either you have some sort of non-blocking IO lib or use threads with limited thread pool?
yep. The only "blocking" calls that should be in go blocks are the parking >! <! operations.
besides that you can quickly get around things by tossing the call into a
and also remember that channels are very useful even outside of a core.async, go block context
@U1XTUTPMY you mean using the blocking variants like
alts!!, etc., perhaps with buffered channels? kind of like queues for decoupling components of your system?
The channels don't even need to have buffers, but if you give them buffers then they are perfectly fine queues.
There are plenty of reasons to have them without buffers still. See
SynchronousQueue in Java
for instance, you could have a plain thread that is blocking on io and then
>!! into a channel. one or more go blocks could be parked on that channel waiting for the input.
a potential way to push the I/O to the outer edges of the program and ferry it into the core.async machinery if needed.
I was wrestling with similar questions a while back. Seems like there a very common need for a companion library that deals with this kind of stuff.
we don't really monitor channels at work. we have some custom buffer types that report metrics, but those aren't really used, we mostly generate metrics for processes reading and writing to channels. how often they loop, how long each loop takes, how many messages they are sending out as they loop
using custom buffer types for monitoring channels isn't that great, because buffers are only used if a channel cannot immediately hand off