Runtime and lifecycle
The framework's process model has four pieces:
| Trait | Responsibility |
|---|---|
Module | Validates configuration and prepares one owned Worker |
Worker | Runs one supervised task until shutdown |
Runtime | Starts prepared workers and drains them |
Shutdown | Signals that the process should stop |
They live in iet-app. The Tokio implementation of
Runtime lives in iet-runtime-tokio.
The lifecycle
flowchart LR A["Application::run_until"] --> B["Modules::prepare"] B --> C["Module::prepare"] C --> D["Worker prepared"] D --> E["Runtime::run"] E --> F["Workers::start"] F --> G["TaskSpawner::spawn"] G --> H["Worker::run with Shutdown"] H --> I["Bounded drain"]
Application accumulates injected modules, prepares them one by one, then hands
the resulting workers to the selected runtime. The runtime starts every worker
and waits for the caller's shutdown future before draining.
use ;
use AppResult;
;
;
Rules worth knowing
- Empty or duplicate
Module::NAMEvalues fail before any worker is prepared. - If a later
preparefails, earlier prepared workers are dropped. TheirDropimplementations must release resources. - Preparation is ordered and happens before any worker starts.
- The runtime does not install signal handlers. The composition root chooses the shutdown future, such as Ctrl+C.
- An HTTP listener is a module too.
iet-http-axumimplementsModuleandWorkerfor its host, so the same lifecycle covers servers and background jobs. - A single HTTP listener does not require
Application; the composition root may drive the host directly. Use the lifecycle when several modules must start and drain together.
Where the pieces live
iet-app—Application,Module,Worker,Runtime,Shutdown, health probes.iet-runtime-tokio— supervised Tokio tasks and bounded drain.iet-http-axum—HttpHostas a module and worker.iet-config— theConfigSourcepassed toprepare.