Files
clice/docs/en/architecture.md
ykiko 75b9ea05b8 refactor(server): split into service layer, add agentic protocol, adopt task_group (#437)
## Summary

- **Restructure `src/server/` into subdirectories** (`service/`,
`compiler/`, `worker/`, `workspace/`, `protocol/`) to separate concerns:
transport/session management, compilation, worker orchestration, and
persistent workspace state.
- **Decouple MasterServer from transport**: MasterServer no longer holds
a `JsonPeer&` reference or registers handlers itself. New `LSPClient`
and `AgentClient` classes own their peer references and register
protocol handlers, accessing MasterServer internals via `friend class`.
- **Add agentic protocol**: A TCP-based side channel
(`agentic/compileCommand`) that lets external tools (AI agents, build
systems) query compile commands from a running clice server. Includes a
CLI client mode (`--mode agentic --port N --path FILE`), server-side
listener when `--port` is specified in pipe mode, and integration tests
for happy path, fallback, concurrency, and connection-refused.
- **Replace fire-and-forget `loop.schedule()` with `kota::task_group`**:
Compiler compile tasks, Indexer background indexing + resource monitor,
WorkerPool worker monitors, and socket accept loops now use structured
concurrency. This eliminates manual `alive_count_`/generation counters
and ensures all spawned tasks are joined on shutdown.
- **Fix flaky integration test**: `CliceClient.initialize()` now always
sets `cache_dir` to a workspace-local `.clice/` directory, preventing
stale PCH artifacts from the global `~/.cache/clice/` from polluting
test runs.

## Details

**Compiler peer lifetime**: `Compiler` and `Indexer` previously took
`JsonPeer&` in their constructors, coupling them to a single connection.
They now store a `JsonPeer*` set via `set_peer()`, with null checks
before sending diagnostics/progress. This supports the multi-connection
model where agentic clients don't need diagnostics.

**Socket mode single-LSP enforcement**: `accept_connections()` takes a
`register_lsp` flag; when true, only the first connection gets an
`LSPClient`. All connections get an `AgentClient`. This prevents
multiple LSP sessions from racing on shared server state.

**Structured shutdown**: `Compiler::stop()` cancels in-flight compile
tasks and joins them. `WorkerPool::stop()` signals workers and joins the
monitor task group. `Indexer` uses a `cancellation_source` to stop its
resource monitor when a background indexing run completes.

**Pin kotatsu**: Changed from `GIT_TAG main` + `GIT_SHALLOW TRUE` to an
exact commit hash for reproducible builds.

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-02 01:06:18 +08:00

184 lines
10 KiB
Markdown

# Server Architecture
clice uses a **multi-process architecture** where a single **Master Server** coordinates multiple **Worker** processes. This design isolates Clang AST operations (which are memory-heavy and may crash) from the main LSP event loop.
## Overview
```
┌──────────────┐ JSON/LSP ┌────────────────┐ Bincode/IPC ┌──────────────────┐
│ LSP Client │ ◄──────────► │ Master Server │ ◄─────────────► │ Stateful Workers │
│ (Editor) │ (stdio) │ │ (stdio) │ (AST cache) │
└──────────────┘ │ - Lifecycle │ └──────────────────┘
│ - Documents │
│ - CDB │ Bincode/IPC ┌──────────────────┐
│ - Build drain │ ◄─────────────► │ Stateless Workers│
│ - Indexing │ (stdio) │ (one-shot tasks)│
└────────────────┘ └──────────────────┘
```
## Master Server
The master server (`src/server/master_server.cpp`) is the central coordinator. It runs a single-threaded async event loop and never touches Clang directly. Its responsibilities:
### LSP Lifecycle
The server progresses through these states:
1. **Uninitialized** — waiting for `initialize` request
2. **Initialized** — capabilities exchanged, waiting for `initialized` notification
3. **Ready** — workers spawned, workspace loaded, accepting requests
4. **ShuttingDown**`shutdown` received, draining work
5. **Exited**`exit` received, stopping the event loop
On `initialized`, the master:
- Loads configuration from `clice.toml` (or uses defaults)
- Starts the worker pool (spawns stateful + stateless processes)
- Loads `compile_commands.json` and builds an include graph
- Starts the background indexer coroutine (if enabled)
### Document Management
Each open document is tracked in a `DocumentState` with:
- Current `version` and `text` (kept in sync via `didOpen`/`didChange`)
- A `generation` counter to detect stale compile results
- Build state flags (`build_running`, `build_requested`, `drain_scheduled`)
When a document is opened or changed:
1. The include graph is re-scanned (via dependency directives)
2. The compile unit is registered/updated in the `CompileGraph`
3. A debounced build is scheduled
### Build Drain
The `run_build_drain` coroutine implements debounced compilation:
1. Wait for the debounce timer (default 200ms) to expire
2. Ensure PCH/PCM dependencies are ready via `CompileGraph`
3. Send a `compile` request to the assigned stateful worker
4. Publish diagnostics from the result (or clear them on failure)
5. If more edits arrived during compilation (`build_requested`), loop back to step 2
This ensures rapid typing doesn't trigger a compile per keystroke.
### Request Routing
Feature requests are split between two worker types:
**Stateful workers** (affinity-routed by file path):
- `textDocument/hover`
- `textDocument/semanticTokens/full`
- `textDocument/inlayHint`
- `textDocument/foldingRange`
- `textDocument/documentSymbol`
- `textDocument/documentLink`
- `textDocument/codeAction`
- `textDocument/definition`
**Stateless workers** (round-robin):
- `textDocument/completion`
- `textDocument/signatureHelp`
All feature responses use `RawValue` passthrough — the worker serializes the LSP result to JSON, and the master forwards the raw JSON bytes to the client without deserializing. This avoids bincode↔JSON conversion overhead and serde annotation conflicts.
## Worker Pool
The worker pool (`src/server/worker_pool.cpp`) manages spawning and communicating with worker processes. Each worker is a child process of the same `clice` binary, launched with `--mode stateful-worker` or `--mode stateless-worker`.
### Communication
Workers communicate with the master via **stdio pipes** using a **bincode** serialization format (via `kota::ipc::BincodePeer`). This is more compact and faster than JSON for internal IPC, while the master handles JSON for the external LSP protocol.
### Stateful Worker Routing
Stateful workers use **affinity routing**: each file is consistently assigned to the same worker so that the worker retains the cached AST. Assignment uses a **least-loaded** strategy for new files, with **LRU tracking** to manage ownership.
When a worker exceeds its document capacity (currently hardcoded at 16 documents), it evicts the least-recently-used document and notifies the master via an `evicted` notification.
### Stateless Worker Routing
Stateless workers use simple **round-robin** dispatch. Each request includes the full source text and compilation arguments, so any worker can handle it independently.
## Stateful Worker
The stateful worker (`src/server/stateful_worker.cpp`) caches compiled ASTs in memory. Key behavior:
- **Compile**: Parses source code into a `CompilationUnit`, caches the AST, and returns diagnostics as a `RawValue` (JSON bytes)
- **Feature queries**: Look up the cached AST and invoke the corresponding `feature::*` function (hover, semantic tokens, etc.), serializing the result to JSON
- **Document updates**: Received as notifications — the worker updates the stored text and marks the document as `dirty`, causing feature queries to return `null` until recompilation
- **Eviction**: LRU-based; evicts the oldest document when capacity is exceeded, notifying the master
- **Concurrency**: Each document has a per-document `kota::mutex` (strand) to serialize compilation and feature queries. Heavy work (compilation, feature extraction) runs on a thread pool via `kota::queue`.
## Stateless Worker
The stateless worker (`src/server/stateless_worker.cpp`) handles one-shot requests that don't benefit from cached ASTs:
- **Completion**: Creates a fresh compilation with `CompilationKind::Completion` and invokes `feature::code_complete`
- **Signature help**: Similar to completion, using `feature::signature_help`
- **Build PCH**: Compiles a precompiled header to a temporary file
- **Build PCM**: Compiles a C++20 module interface to a temporary file
- **Index**: Compiles a file for indexing (TUIndex generation — currently a stub)
All requests are dispatched to a thread pool via `kota::queue`.
## Compile Graph
The compile graph (`src/server/compile_graph.cpp`) tracks compilation unit dependencies as a DAG. It handles:
- **Registration**: Each file registers its included dependencies
- **Cascade invalidation**: When a file changes, all transitive dependents are marked dirty and their ongoing compilations are cancelled
- **Dependency compilation**: Before compiling a file, `compile_deps` ensures all dependencies (PCH, PCMs) are built first
- **Cancellation**: Uses `kota::cancellation_source` to abort in-flight compilations when files are invalidated
## Configuration
The server reads configuration from `clice.toml` (or `.clice/config.toml`) in the workspace root. If no config file exists, sensible defaults are computed from system resources:
| Setting | Default | Description |
| ------------------------ | --------------------- | ------------------------------------------- |
| `stateful_worker_count` | CPU cores / 4 | Number of stateful worker processes |
| `stateless_worker_count` | CPU cores / 4 | Number of stateless worker processes |
| `worker_memory_limit` | 4 GB | Memory limit per stateful worker |
| `compile_commands_path` | auto-detect | Path to `compile_commands.json` |
| `cache_dir` | `<workspace>/.clice/` | Cache directory for PCH/PCM files |
| `debounce_ms` | 200 | Debounce interval for recompilation |
| `enable_indexing` | true | Enable background indexing |
| `idle_timeout_ms` | 3000 | Idle time before background indexing starts |
String values support `${workspace}` substitution.
## IPC Protocol
The master and workers communicate using custom RPC messages defined in `src/server/protocol/`. Each message type has a `RequestTraits` or `NotificationTraits` specialization that defines the method name and result type.
### Stateful Worker Messages
| Method | Direction | Purpose |
| ----------------------------- | ------------ | ------------------------------------- |
| `clice/worker/compile` | Request | Compile source and return diagnostics |
| `clice/worker/hover` | Request | Get hover info at position |
| `clice/worker/semanticTokens` | Request | Get semantic tokens for file |
| `clice/worker/inlayHints` | Request | Get inlay hints for range |
| `clice/worker/foldingRange` | Request | Get folding ranges |
| `clice/worker/documentSymbol` | Request | Get document symbols |
| `clice/worker/documentLink` | Request | Get document links |
| `clice/worker/codeAction` | Request | Get code actions for range |
| `clice/worker/goToDefinition` | Request | Go to definition at position |
| `clice/worker/documentUpdate` | Notification | Update document text (marks dirty) |
| `clice/worker/evict` | Notification | Master → Worker: evict a document |
| `clice/worker/evicted` | Notification | Worker → Master: document was evicted |
### Stateless Worker Messages
| Method | Direction | Purpose |
| ---------------------------- | --------- | ---------------------------- |
| `clice/worker/completion` | Request | Code completion at position |
| `clice/worker/signatureHelp` | Request | Signature help at position |
| `clice/worker/buildPCH` | Request | Build precompiled header |
| `clice/worker/buildPCM` | Request | Build C++20 module interface |
| `clice/worker/index` | Request | Index a translation unit |