Expand description
The publish side: the one place a snapshot can change.
§What this file is for
crate::domain::registry::Snapshot knows how to describe a set of
primitives and refuses to be edited. This module is what a server calls when
a tool is registered, and its whole job is the sequence copy, change,
swap. The copy is shallow — every primitive is behind an Arc — so a
thousand unchanged tools cost a thousand pointer copies rather than a
thousand clones of the tools.
§Why the swap is the transaction boundary
A reader that held &Snapshot could not survive a publish at all, and a
reader that held a Guard would pin the old snapshot against reclamation
for as long as it lives. A tools/call that resolves a tool and then runs
it — which may block on a network call, a sandbox, or a human — would hold
the registry’s old state against a publish for that whole duration. So the
reader takes an owned Arc<Snapshot>, the writer replaces the Arc, and
the two never share a borrow.
The consequence worth stating: an in-flight call runs against the snapshot it started with. A tool removed a microsecond after a call resolved still completes. That is not a best-effort approximation, it is the only behaviour that does not make a publish block on a running tool.
§The generation
Every snapshot carries the number of the publish that produced it, and
RegistryStore::generation reads it off the current value rather than
keeping a counter beside it — a counter that could drift from what it
describes. A session that was told about generation N can compare one
u64 to learn whether anything changed, which is what makes the fan-out in
super::subscriber able to skip a notification it has already sent.
Structs§
- Published
- What a publish did, as the caller needs to hear it.
- Registry
Store - The live set, and the only way to change it.