Are thread blocks daemonized?

Besides not being supposed to spin off unbounded uncontrolled tasks (I.e. your code's design should block on something waiting Dir them to finish), you can add a JVM shutdown hook. Maybe

Yep.

(defonce ^:private ^Executor thread-macro-executor
  (Executors/newCachedThreadPool (conc/counted-thread-factory "async-thread-macro-%d" true)))

Nice. Anyway, this can be solved by design - never spin up a thread or go block that no one waits for. In the end, you'll see your main thread waits for something to finish

Hm. So basically I would need to manage my own thread pool for workers to block until their read channel closes?

Can you describe your use case? The good old "what are you trying to do" Code samples help, too

Sure. I want to have an in-process event broker so that I can publish things happening and not caring what will need to happen as a reaction. Could be as simple as:

(def publish-chan (chan))
(def the-pub (pub chan first))

(put! publish-chan [:something-happened {}])

(let [ch (chan)]
  (sub the-pub :user-logged-in ch)
  (go-loop [] (when [msg (<! ch)] (thread (send-to-slack msg)) (recur))))

Instead I would need to somehow have one ore more “slack worker threads” running and blocking on a channel.

lots of unbounded resources here

The mistake here is you have two fire-and-forget-s

three even

one is putting on the channel. Always respect back pressure two is you should wait on the go-loop to terminate three you should wait for the thread to finish

You should use pipeline-blocking , which will manage it for you, and connect some sort of "drain" to the results channel

One - well I literally wrote about that, this was just an example. I could also decide to use a windowed buffer and fire-and-forget — this is about decoupling after all

Not precisely, fire and forget is like goto, it has unfortunate results, just like you found out

So you should always have a way of finding out a go block or thread finished, never just spin them up

pipelines give you an abstraction which is similar to a worker pool

And if you don't make sure the items are dropped you'll get an exception if you put items too fast on the channel

(1024 pending puts)

Sure, but this would not happen with >!!

E.g. that’s not the point. But you made good points about waiting on the subscriber side

Maybe I could just mix all the subscribers into one channel, and wait for this one to close in the main thread

Remember that putting and taking are synchronization points. You block your execution flow if you >!!, which you might not want.

That's an option

Sure, but this is about back-pressure, right?

I mean I want to publish and then go on. With a large enough buffer, should be OK. But when the buffer is full, I think it would be better to block

Yes, and/but - your way to control this unbounded concurrency problem is by turning it into back-pressure

Btw, why pubsub here and not a multimethod?

To allow for multiple subscribers

then (pipeline-blocking n to (map your-mfn) from)?

Ah, multiple handlers for same message

ack

Yep.

in that case, I'd create the subs, pipeline them, then mix them all back and wait for that to finish

I actually want to bundle all that async stuff in one place, So that my “main logic” can stay simple

then you have clean graceful shutdown

Yep, that makes sense.

Thanks a lot!

Nice thing about this pattern is you know for certain everything finished if you wait on the end channel

I really like this pattern