Clojurians Log v2

I forget, but I am not sure stacking tool names works like that, and the execution environment of the tool is not the same thing as what the tool calculates

List has an :aliases argument I believe

https://clojure.org/guides/deps_and_cli#list_deps, hmmm, i guess i should follow the "more info" bit suggested by the clj tool. It's probably worth me reading the full docs on it again, i use it enough 🙂

thanks!!!!

i see clojure-agent-send-pool-0 alive=true daemon=false in your example. When you use future i see CLI-agent-send-off-pool-0 alive=true daemon=true

The setting of the executor would happen after any user.clj

i’m not able to find where the executor is set

It is part of the machinery for -X which lives in a whackodo place and is impossible to find

https://github.com/clojure/brew-install/blob/1.12.0/src/main/clojure/clojure/run/exec.clj#L222

Context: https://clojurians.slack.com/archives/C0617A8PQ/p1743382781902199?thread_ts=1743365153.832239&cid=C0617A8PQ

ahh. brew-install not homebrew tools 🙂

The swapping out doesn't effect any already running threads

So one possibility is if you have a user.clj somewhere or something that is starting futures

Hum... maybe. Let me check.

(.setDaemon true) ;; DIFFERENT

The name is different too: CLI-agent-send-off-pool-%d

And I think it must be a race like that, because the daemon thread executor uses different names

Let me see if I also have threads named CLI

Ah!

And it only does it for the send-off pool

And your example uses the send pool

Oh, the send-off pool... I can test with that as well to compare. I don't see threads named with CLI.

wait. this is two separate ones

volatile public static ExecutorService pooledExecutor =
	Executors.newFixedThreadPool(2 + Runtime.getRuntime().availableProcessors(), 
		createThreadFactory("clojure-agent-send-pool-%d", sendThreadPoolCounter));

volatile public static ExecutorService soloExecutor = Executors.newCachedThreadPool(
	createThreadFactory("clojure-agent-send-off-pool-%d", sendOffThreadPoolCounter));

i always get these confused

Ya, when I use send-off, I see them now: clojure-agent-send-pool-0 alive=true daemon=false CLI-agent-send-off-pool-0 alive=true daemon=true But there is also a send thread and so it still holds up my invocation.

Those threads are created when they are used

So something is using the send pool for you for some reason

If I comment out my agent code, no agent thread is created and the invocation exits. So I don't think it's something on my global setup.

Await uses the send pool of course

Maybe send-off or (agent ...) also ends up using a thread from the send executor ?

In your snippet you send to an agent. It seems correct to use the send pool?

Right. If I don't await, and use send-off it exits.

Ok, so issue is, clojure -X only makes the send-off pool daemon, not the send pool.

I don't know if this was intentional or not, but it means if you -X invoke anything that uses the send pool, it'll prevent the invocation to exit when done.

I didn't even know it did that, I bet it was added because the new process stuff uses a future somewhere to copy between streams

It doesn't prevent the exit

The agent pools by default get rid of any threads that haven't been used in a minute

So it will exit after around a minute (assuming the thread is actually idle)

It makes sense to me to be honest with -X that it would do that. In my case, it's using the test-runner with -X to run tests, when my tests use the send pool.

Don't want to wait 1 min when the tests themselves are done in like 2 seconds 😛

But just in general, you'd like to expose -X functions, without having to add shutdown-agents after them, cause if you do, then you can't use the functions as functions in the code anymore, but only as -X invocation entry points.

> I bet it was added because the new process stuff uses a future somewhere to copy between streams no, it was added before that existed so that using future etc in a -X would not prevent exit (which imo is how the core pools should work - I filed a jira about this in like 2010 but never successfully convinced Rich, it's still open :) the process stuff uses it's own daemon threads for io stream copying

probably -X should also be swapping the send pool

Not yet