core-async

souenzzo 2020-02-17T14:14:36.372400Z

How do I know which JAVA methods are "blocking safe"? This takeFirst is non-blocking? https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/BlockingDeque.html#takeFirst()

mpenet 2020-02-17T14:16:58.372800Z

"Retrieves and removes the first element of this deque, waiting if necessary until an element becomes available." guess not

souenzzo 2020-02-17T14:18:52.373400Z

And https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Deque.html#pollFirst() ? I can only know if the docstring says waiting ?

souenzzo 2020-02-17T14:20:10.373900Z

There is a ready impl of BlockingDeque piping into chan ?

markmarkmark 2020-02-17T14:25:40.374500Z

in the case of BlockingDeque, there's actually a table that specifies which methods block at the top of the javadoc

markmarkmark 2020-02-17T14:28:40.375800Z

if you wanted to bring a BlockingDeque and core.async together, I would expect lots of calls to async/thread

markmarkmark 2020-02-17T14:29:03.376Z

or at least one per Deque

souenzzo 2020-02-17T15:19:22.376300Z

I end up with

(async/thread
  (loop []
    (let [tx (.take tx-queue)]
      (async/put! conn-chan tx))
    (recur)))

mpenet 2020-02-17T15:22:39.376900Z

you can also just use future instead of async/thread if you don't take from the returned chan

2020-02-17T18:54:55.377200Z

Use >!! Otherwise you are missing back pressure from the consumer of conn-chan

2020-02-17T18:57:20.377400Z

Using put! naively is very bad, using >!! often just does the right thing

souenzzo 2020-02-17T19:07:35.377600Z

conn-chan is a sliding buffer. It will just pub/sub it's value

conn-chan (async/chan (async/sliding-buffer 1))

Ben Sless 2020-02-17T19:23:30.377800Z

Hi all, I'm trying to create an async process which takes messages from an input channel, times them out, then passes them to output channel. Order is not important. As you can see, there's a bug in my implementation, both in that it doesn't create backpressure, and that it'll throw exceptions if n+1024 messages are consumed before being retired. Any recommendations on how to fix this, and without hitting the maximum put limit, such as with pipeline-async w/ n>1024?