Fork me on GitHub

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

👀 1

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 feature that channels have that is hard to replicate with java queues is closing


another feature is alts (no-deterministic choice over a collection of reads and writes)

Alex Miller (Clojure team)18:08:59

LinkedTransferQueue is like a channel with a buffer

👀 2

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!