mirror of https://github.com/sbt/sbt.git
Updated Client server discovery lifecycle (markdown)
parent
9068be9087
commit
6f9e77874b
|
|
@ -47,3 +47,28 @@ This proposal is intended to "self-heal" and work in practice without asking use
|
||||||
## Proposal 2: Some other idea here
|
## Proposal 2: Some other idea here
|
||||||
|
|
||||||
* is there some way we can get an actual, reliable lock on a project directory, cross-platform?
|
* is there some way we can get an actual, reliable lock on a project directory, cross-platform?
|
||||||
|
|
||||||
|
The sbt launcher provides a locking facility.
|
||||||
|
|
||||||
|
* currently used in practice to:
|
||||||
|
+ lock down the Ivy cache
|
||||||
|
+ lock parts of the sbt boot directory
|
||||||
|
* locks access jvm-wide on a file
|
||||||
|
+ combination synchronized + file lock
|
||||||
|
+ only allows one thread across all (cooperating) Java processes
|
||||||
|
* deals with some weird implementation details
|
||||||
|
+ overlapping file lock exceptions from Java when locking in the same JVM
|
||||||
|
+ workaround OS deadlock detection, which is often spurious in a multi-threaded application
|
||||||
|
* won't magically work on NFS or other environments with poor/missing lock support
|
||||||
|
* OS will clean up the lock if the process locking it dies
|
||||||
|
* blocking only- no tryLock to only attempt a lock and return quickly if not available
|
||||||
|
* API for [File.createNewFile](http://docs.oracle.com/javase/6/docs/api/java/io/File.html#createNewFile%28%29) says it shouldn't be used for file locking (don't know why)
|
||||||
|
* could use for server startup roughly like:
|
||||||
|
```scala
|
||||||
|
val f = <project-lock-file>
|
||||||
|
withLock(f) {
|
||||||
|
val port = read(f)
|
||||||
|
tryConnect(port)
|
||||||
|
fail: port = start new process; write(f, port)
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue