Windows client-server fixes

[sake92]

Only one thing in ClientServerTests doesn't work currently.
Maybe someone will find a fix in the future... 😄

I tried many things, even reimplementing the whole named pipes thing with JNA...
But it boils down to read/write throwing an exception instead of returning -1...
Since the read is done infinitely in a separate thread, it doesn't know when the output from server is done.
So when a connection breaks, we should just ignore it, and not System.exit(1); as currently.

[lefou]

Looks good to me. I added a question below. Does this PR really fix the server mode on Window, so that you no longer need the --no-server settings?

[sake92]

Looks good to me. I added a question below. Does this PR really fix the server mode on Window, so that you no longer need the --no-server settings?

It works 99% of the time.
It throws this exception when you run mill on another project:

Exception in thread "main" java.io.IOException: Could not create lock for \\.\pipe\mill.ghrxuj6QppDw=-1_lock, error 5
        at org.scalasbt.ipcsocket.Win32NamedPipeServerSocket.<init>(Win32NamedPipeServerSocket.java:104)

That's because there should only be one locked pipe.
But we give it the same pipe name, based on JDK we're running...
Not sure how to improve on this one?

But after that it works fine. 😄
This PR is a big improvement on status quo IMHO.

[sake92]

@lefou I think we can take inspiration from Gradle deamon docs.
It spawns a new deamon per JDK+(JVM properties).
That seems reasonable because not all projects use same props, maybe even in tests you want different props?

Then, it doesn't seem logical to lock on processLock/serverLock because JDK/daemon should be global for all its clients, not per-project... (thus the exception above)

[lefou]

Thanks for this PR. I'll merge it. Nice to have mill server support on Windows.

@sake92, regarding the daemon: The mill daemon does not take multiple clients at once. Also I think we don't abstract the current working directory away in all cases, esp. when spawning sub-processes. So for having a shared daemon there is some more work to do...