Runtime and lifecycle

The framework's process model has four pieces:

TraitResponsibility
ModuleValidates configuration and prepares one owned Worker
WorkerRuns one supervised task until shutdown
RuntimeStarts prepared workers and drains them
ShutdownSignals 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.

rust
use iet_app::{Application, Module, Shutdown, Worker};
use iet_core::AppResult;

struct WorkerModule;
struct ServiceWorker;

impl Module for WorkerModule {
    const NAME: &'static str = "service";
    type Worker = ServiceWorker;

    async fn prepare<C: iet_config::ConfigSource>(
        self,
        config: &C,
    ) -> AppResult<Self::Worker> {
        // Read settings and acquire owned resources here.
        Ok(ServiceWorker)
    }
}

impl Worker for ServiceWorker {
    async fn run<S: Shutdown>(self, stop: S) -> AppResult<()> {
        stop.cancelled().await;
        Ok(())
    }
}

Rules worth knowing

  • Empty or duplicate Module::NAME values fail before any worker is prepared.
  • If a later prepare fails, earlier prepared workers are dropped. Their Drop implementations 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-axum implements Module and Worker for 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 — HttpHost as a module and worker.
  • iet-config — the ConfigSource passed to prepare.
IET Framework documentation — built with the IET Framework.