Fork me on GitHub
#core-async
<
2022-08-15
>
andersmurphy18:08:56

If I want one way communicate between two threads. Is there any reason to use core.async channels over an atom containing a PersistentQueue?

hiredman18:08:26

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)

hiredman18:08:36

pqs in an atom also are not blocking, you can't have your thread stop until a new item is added

hiredman18:08:32

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
andersmurphy18:08:06

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.

hiredman18:08:07

a feature that channels have that is hard to replicate with java queues is closing

hiredman18:08:43

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
andersmurphy19:08:24

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.

andersmurphy19:08:47

Thank you both for your help!