It's a bit risky to have uncontrollable puts on channels. You can theoretically start throwing exceptions

sorry, what do you mean by uncontrollable puts?

You could have only this part

(async/go (when-not (async/>! tracking-channel message)
                (log/debug "Failed to send")))

this is still fragile. Imagine the tracking channel is full but you still call your function, what happens?

The problem is if you call the function over 1024 you subscribe over 1024 pending puts on the channel and start getting exceptions

you have to provide some back pressure mechanism. One way to do it is to always return a go block and park on it

This is where core.async leaks

In the example you can use put! instead

@UK0810AQ2 > One way to do it is to always return a go block and park on it yes that’s what I meant, so you can control if you park/block depending from where you are calling the fn

So the fn doesn’t need to know if it’s inside go or not, and it shouldn’t imo, that’s what channels are for, to communicate threads and go processes

Well, you shouldn't use >!! inside a go-block, but if you push or pull from a channel inside a spawned logical process (i.e. go block or thread) you must provide some back pressure mechanism

i.e. wait on that process

Correct, I meant only the first branch of the if should be the whole fn, so the go block ch is the return of the fn

I think it depends on the context, but why not directly putting message in tracking ch on whenever you need to, either with >! or >!!?

Thanks a lot for the input! I need to process it 🙂 It is a while since I worked with Async...

I believe the answer to your question is “no”, as far as I understand it.

In terms of backpressure, the concern is real. You can utilize https://clojuredocs.org/clojure.core.async/dropping-buffer https://clojuredocs.org/clojure.core.async/sliding-buffer https://clojuredocs.org/clojure.core.async/offer!!

… depending on the result you want to achieve.

Long story short, you always should have some policy/strategy what happens when there’s “too much stuff” inside your system and the system can’t keep up. For example, offer! will only return true if the offered value is successfully put onto the channel. When it does not return true , you need to decide what to do: 1. Forget about the value? 2. Try again? 3. “Store” the value elsewhere, and try to process later? 4 Etc.

It all depends on the use case. Some things are OK to be best effort delivery (say, performance metrics); E-commerce transactions, less so.

Re: your question. Spawning an extra (go …) block just to write to a channel is not a good idea. It will not bring any benefit. Generally, outside of (go …) blocks use (put! …) and/or (offer! …) and use a backpressure strategy that works for you.

And btw, just noticed: Your question says “read from a channel” but from what I can tell, your function as written puts values onto the channel (I guess that would be a “write”? 🙂 ) In core.async lingo, the phrases “take values from a channel” and “put values onto a channel” are used more often to eliminate confusion. If you haven’t watched Rich Hickey’s talks on core.async, I highly recommend them.

Thank you! And yes, "put" would be right.