This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-15
Channels
- # architecture (5)
- # babashka (34)
- # beginners (72)
- # calva (42)
- # cherry (31)
- # cider (14)
- # clojure (27)
- # clojure-europe (11)
- # clojure-norway (17)
- # clojure-uk (1)
- # clojurescript (25)
- # community-development (13)
- # conjure (1)
- # core-async (11)
- # datascript (18)
- # datomic (11)
- # emacs (12)
- # fulcro (10)
- # integrant (5)
- # introduce-yourself (3)
- # jobs (8)
- # juxt (2)
- # malli (22)
- # off-topic (11)
- # pathom (18)
- # polylith (62)
- # rdf (18)
- # reagent (8)
- # releases (1)
- # shadow-cljs (35)
- # sql (3)
- # squint (141)
- # tools-deps (12)
- # vim (4)
- # xtdb (4)
If I want one way communicate between two threads. Is there any reason to use core.async channels over an atom containing a PersistentQueue?
it depends, but a pq in an atom has some annoying ergonomics (you need to remove two operations to dequeue something, peek then pop, squaring that with atoms is doable, but annoying)
pqs in an atom also are not blocking, you can't have your thread stop until a new item is added
if you just don't want to pull in core.async, java.util.concurrent comes with a variety of useful queues, I usually start with a java.util.concurrent.LinkedBlockingQueue
Ahh didn’t think about the non blocking part. Thanks for the java.util.concurrent.LinkedBlockingQueue suggestion. Was just wondering wether using core.async only for channels wasn’t a bit overkill.
a https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/SynchronousQueue.html is sort of like a core.async channel with no buffer
another feature is alts (no-deterministic choice over a collection of reads and writes)
I’ll give LinkedTransferQueue a try (as that seems to be exactly what I was looking for). Though it sound like using core.async might save me some pain in the long run. I just wasn’t particularly needing the asynchronous part.
Thank you both for your help!