Summary
The swarm runtime (#34) uses a dedicated OS thread plus bounded command/event channels, with std.Io.Threaded providing futex-backed Io.Mutex / Io.Condition / Io.Event for cross-thread sync. That matches the first milestone and keeps a simple embedder boundary (submit / nextEvent).
Enhancement
Evaluate a deeper integration with Zig 0.16 std.Io async patterns (tasks, Future, cancelation, unified timeouts)—sometimes discussed as “zig-async” in the ecosystem—so the swarm can be co-scheduled with transport (zquic, TCP, etc.) on a single Io runtime instead of (or in addition to) a dedicated thread.
Possible directions called out in #34’s discussion:
- A
Swarm.tick() (or equivalent) that drains command and transport work from an embedder-driven Io loop.
- Optional replacement or complement to
startBackground / run when the process already owns Io and wants fewer threads and consistent cancelation across operations.
When this is worth doing
- The node (e.g. Zeam) moves toward one primary Io loop and wants gossip/req-resp on the same scheduler as the rest of I/O.
- Cross-cutting cancelation and timeout behavior should apply uniformly to swarm-adjacent work.
When to keep the current model
- FFI or glue-layer parity where a fixed worker thread and blocking / timeout-based event pull stay the clearest contract.
- Minimal coupling to Io task lifetimes on the embedder side.
Non-goals (for this issue)
- No requirement to remove the threaded API; a follow-on could offer both shapes behind clear docs.
References
Summary
The swarm runtime (#34) uses a dedicated OS thread plus bounded command/event channels, with
std.Io.Threadedproviding futex-backedIo.Mutex/Io.Condition/Io.Eventfor cross-thread sync. That matches the first milestone and keeps a simple embedder boundary (submit/nextEvent).Enhancement
Evaluate a deeper integration with Zig 0.16
std.Ioasync patterns (tasks,Future, cancelation, unified timeouts)—sometimes discussed as “zig-async” in the ecosystem—so the swarm can be co-scheduled with transport (zquic, TCP, etc.) on a single Io runtime instead of (or in addition to) a dedicated thread.Possible directions called out in #34’s discussion:
Swarm.tick()(or equivalent) that drains command and transport work from an embedder-driven Io loop.startBackground/runwhen the process already ownsIoand wants fewer threads and consistent cancelation across operations.When this is worth doing
When to keep the current model
Non-goals (for this issue)
References
std.Io/Io.Threadedin Zig 0.16