multi process setup

[drue]

I am running the same mill build in four places at the same time on the same machine - VSCodium/Metals, a coding agent (pi) running in a container, a script that watches for changes and runs mill on the host to generate a classpath and reloads the app which also runs in containers (maybe I don't need a separate script for this,) and I run mill manually for tests also in a container.

I frequently work on a laptop so I don't want to waste battery compiling anything more than once and of course I don't like to wait so ideally there is one mill daemon running that everything uses and only one compile happens at a time. I can't get this to work though, mill daemon mode doesn't seem to work the way I expect. It seems each mill user (metals, agent, command-line) starts its own daemon.

I mount the mill directory in the containers (and coursier caches) and set MILL_NO_SEPARATE_BSP_OUTPUT_DIR in an attempt to only compile everything once, which works if I use external locking to keep mill daemons from crashing.

I'm guessing I'm having trouble because daemon mode is just so you have a warm jvm for compilation and not so you can have multiple users sharing a mlll daemon and output directory. If I'm using it wrong please let me know.

[lihaoyi]

Currently Mill has one daemon per folder in which it is run. That is a pretty fundamental architecture and isn't likely to change anytime soon.

You can mitigate the problem somewhat by using Mill 1.1.6-33-43d8dd, which has MILL_NO_SEPARATE_BSP_OUTPUT_DIR on by default and does its own fine-grained locking to avoid conflicts, so at least it goes from 2 daemons per folder open in the IDE to 1 daemon per folder

[drue]

one daemon per folder is what I want but the locking isn't working. When my agent makes changes in a container with the workarea and mill output folder mounted and then runs mill while I have mill --watch and metals running on the host it causes the daemon to crash. I get a trace like this in vscode and the watcher exits. When I try to run mill --watch again I get this trace again until I restart vscodium

this is with 1.1.6-33-43d8dd

java.lang.IllegalStateException: Mill daemon terminated unexpectedly. Connection DaemonRpcClient
at mill.rpc.MillRpcClient$.mill$rpc$MillRpcClient$$$_$awaitForResponse$1(MillRpcClient.scala:62)
at mill.rpc.MillRpcClient$$anon$1.apply(MillRpcClient.scala:95)
at mill.launcher.MillServerLauncher.runRpc(MillServerLauncher.scala:122)
at mill.launcher.MillServerLauncher.run(MillServerLauncher.scala:52)
at mill.launcher.MillLauncherMain$.runViaDaemon(MillLauncherMain.scala:157)
at mill.launcher.MillLauncherMain$.main0(MillLauncherMain.scala:95)
at mill.launcher.MillLauncherMain$.main(MillLauncherMain.scala:18)
at mill.launcher.MillLauncherMain.main(MillLauncherMain.scala)

[lihaoyi]

Mill in general cannot support locking and mutex across docker mounts as docker mount filesystems do not have support for file locks, so i don't think there's much we can improve here

[drue]

Is the problem that the mill client running in the container can't find the daemon running on the host so it starts its own and/or begins using the output directory directly? Can I fix this with proper configuration or am I confused about the relationship between the mill client and the daemon?

[lihaoyi]

Yes that's right. It cant see the daemon process running inside the container so it doesnt know it needs to block