Concurrency, Parallelism, and Cancellation

Serial input, concurrent derivation

The main loop exclusively applies VFS and configuration changes. Read-only requests use GlobalStateSnapshot on a custom thread pool. This resembles multi-version concurrency control: many readers derive answers from a stable revision while one coordinator advances ground truth.

Salsa supplies dependency-aware reuse

Each query records the input/query facts it read. A changed function body does not invalidate unrelated bodies or crate-wide facts unless dependency edges say it should. Parallel requests can share memoized results through the database rather than each reconstructing a compiler model.

Cancellation is revision invalidation

AnalysisHost::apply_change triggers cancellation before changing inputs. Old Salsa computations detect the new revision and unwind with salsa::Cancelled. RequestDispatcher catches the unwind at the read-only boundary and maps it to retry or LSP content-modified. The main loop remains intact.

Pools encode latency intent

stdx::thread::Pool queues boxed jobs with a ThreadIntent. A separate one-thread formatting pool prevents ordinary semantic work from delaying an editor-blocking rustfmt request. Cache priming and symbol indexing use bounded workers/Rayon for actual CPU parallelism.

Actors isolate I/O and failure

VFS watching, Cargo/flycheck, and proc-macro services communicate through channels. Proc macros run in another process because they may block, panic, segfault, or violate determinism. The language server treats partial project failure as degraded input, not permission to stop serving syntax features.