Skip to content
EN FR

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 classes: registries, providers, queues, models or buffers may require a documented Free or transfer of ownership.
  • Component-owned objects: native MVC/RadStudio objects may be owned by a TComponent, with distinct parent/free-notification rules.
  • Manual Hypergraph values: low-level pointer values such as PNodeValue require native reference-count operations; they are not Delphi interfaces.

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?

Runtime production checklist · ABI ownership · Operational diagnostics

LaTeX sources: runtime-lifetime-ownership-and-shutdown.tex; production-readiness.tex; performance-profiling-and-thread-safety.tex.