Skip to main content

Module runtime

Module runtime 

Source
Expand description

Runtime abstraction so the engine (Client<E>) doesn’t hard-depend on tokio. Executor spawns the background read loop and per-handler tasks; Timer drives request/ping timeouts. Both are dyn-safe (boxed-future style) so Client<E> stays generic over one type parameter only, the same way TransportSink/TransportStream are already boxed instead of threaded through as generics. tokio-runtime (see runtime::tokio) provides the default std impls; embedded users supply their own (e.g. backed by embassy-executor/embassy-time).

Modules§

tokio
tokio-backed Executor/Timer impls, used by connect_1_6/connect_2_0_1 and the crate’s own tests. Gated behind the tokio-runtime feature.

Structs§

Elapsed
Returned by [with_timeout] when duration elapses before fut resolves.

Traits§

Executor
Spawns futures onto a background executor. Implementations must actually run the future to completion independently of the caller awaiting anything - Client::from_transport’s read loop, on()’s per-action handler loop, and on_ping()’s subscriber loop all rely on spawn to keep running in the background.
Timer
Produces timer delays. with_timeout (below) is built on top of this single dyn-safe method rather than a generic timeout<F> method, so Timer itself stays object-safe.