Module embedded_runtime 

Available on crate features embedded and std only.

EmbeddedRuntime — minimal Runtime implementation for embeddings that do not (or cannot) carry tokio (Phase 3.1 scaffold).

Scaffold status. This implementation exists to prove the Runtime trait is implementable off-tokio without dragging in a specific executor crate as a hard dependency. It uses one OS thread per spawned future plus futures::executor::block_on inside that thread to drive the future to completion. That’s correct (every future makes progress, abort actually cancels, sleeps actually wait) but it is not what bare-metal embedded targets want — embassy_executor, RTIC, or an in-house cooperative scheduler is. Production embedders are expected to ship their own impl Runtime; the value of this scaffold is that the trait surface is now demonstrably usable off the default tokio impl, so future executor crates plug in without changing call sites.

The module is gated on both the embedded and std features. Pure no_std support requires the Runtime trait to drop its std::time::{Instant, SystemTime} dependence — tracked as a follow-up under the same Phase 3.1 work.

What this is good for

• Wiring up call sites that take Arc<dyn Runtime> so they can be exercised in non-tokio contexts (e.g. host-side integration tests for the EmbeddedLeg transport).
• Demonstrating cancel-safety (abort actually drops the spawned thread’s block_on future and runs its Drop impls).

What this is NOT good for

• Bare-metal targets (thumbv7em-none-eabihf, etc.) — they have no std::thread. They need an EmbassyRuntime / RticRuntime / custom-scheduler impl. The follow-up PR ships those alongside the no_std refactor of the trait.
• High-task-count workloads. One OS thread per future is fine for a handful of long-lived tasks (handshake driver, accept loop) but a poor match for short-lived spawned work.

Structs

EmbeddedRuntime

Runtime impl that spawns one OS thread per future and drives it with futures::executor::block_on. See module docs for limitations.