Lifetime, ownership and graceful shutdown
Documentation status: guide. Memory lifetime and operational lifetime are different contracts.
Four ownership families
- Reference-counted interfaces: holding an interface may retain its underlying object, but does not imply an open connection or running service.
- Explicitly owned ABI objects: registries, providers, queues, models or buffers require the release or ownership-transfer operation documented by their public contract.
- Component-owned resources: UI components may follow parent–child ownership and destruction notifications. These are implementation details, not a published ABI class contract.
- Low-level Hypergraph handles: native values require the retain/release semantics defined by the ABI; they are not automatically managed by an application wrapper.
Operational cleanup sequence
For each service, channel or worker, decide who accepts new work, who drains pending operations, who waits for callbacks, who disconnects, and who releases the instance. The source book illustrates service hooks in the order Prepare → Start → Stop → Dispose (then destroy the owning object) when the service is managed directly. A service manager may apply these hooks on the application's behalf.
Channel metadata and an opened channel instance can have different lifetimes. Threads and queues must not outlive the resources their callbacks touch; never assume that object destruction alone drains asynchronous work.
Questions to ask before implementation
Who creates and releases the value? Is it shared across threads? Which state survives the current operation? Does Reset clear a logical session, host buffers or backend device memory? Which error or callback can arrive after shutdown begins? Does a resident LLM keep its weights and KV cache across individual decode steps?
Related practices
Runtime production checklist · ABI ownership · Operational diagnostics
LaTeX sources: runtime-lifetime-ownership-and-shutdown.tex; production-readiness.tex; performance-profiling-and-thread-safety.tex.