You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes#5031
* We now only have a single server process running at a time, and no
longer keep up to 5 separate `serverDir-1` to `serverDir-5` folders.
Essentially we are migrating from the style of concurrency used by
`gradle` and `mvnd` to the style of concurrency used by `bazel`
* We now only hold the `clientLock` until the server process is
initialized (and has taken it's `processLock`) to avoid redundant
initialization, and after that we release it to allow multiple clients
to connect
* Since there is only one server and one `serverDir`, we have to remove
several per-server files since there is no way to ensure they are unique
in the presence of multiple clients
* `runArgs` can no longer be a file, and instead we send its contents
over the socket before starting the `InputPumper`
* We can no longer rely on `clientLock` probing to check if the client
has disconnected, and so we instead have the server send
`ProxyStream.HEARTBEAT` bytes (127) and look for errors
* `Server#run` can no longer accept socket connections and process them
in a single-threaded loop, and instead needs to spawn off threads to
handle each connected socket
* We cannot perform the mutex at the server/client/connection level
because there are scenarios we want multiple clients connected at once,
e.g. when one client is in `--watch` mode and idle we want to allow
another client to proceed with execution. So locking needs to be done at
a finer-grained granularity within the server
* The original `millLock` file (renamed `millOutLock`) has been combined
with a `MemoryLock` via `DoubleLock`, which lets us check the
memory-lock first to avoid taking the file-lock twice on the same JVM
and causing a `OverlappingFileLockException`. We still need to keep the
file-lock to provide mutex between server and no-server processes, or
between multiple no-server processes
Now that things are in one process, that opens up the possibility of
loosening the concurrency constraints in future, e.g. allowing multiple
concurrent evaluations that do not interfere with each other.
0 commit comments