One thing the old Zig async/await system theoretically allowed me to do, which I'm not certain how to accomplish with this new io system without manually implementing it myself, is suspend/resume. Where you could suspend the frame of a function and resume it later. I've held off on taking a stab at OS dev in Zig because I was really, really hoping I could take advantage of that neat feature: configure a device or submit a command to a queue, suspend the function that submitted the command, and resume it when an interrupt from the device is received. That was my idea, anyway. Idk if that would play out well in practice, but it was an interesting idea I wanted to try.
I suspect the end goal is to have suspend/resume (or some analogue) be userspace standard library functions used to implement Io.Evented. It'll end up being a userspace implementation like you see with many of the C coroutine libraries floating around on GitHub (minicoro, llco, etc).
Edit: Looking at the working prototype of Io.Evented, this may not be true actually. Perhaps this is the domain of a 3rd-party library except with stackless coroutines?
Another thing you may want to pay attention to, however, are the current proposals for getting evented IO working on WASM -- namely, stackless coroutines as a language feature: https://github.com/ziglang/zig/issues/23446
special @asyncSuspend and @asyncResume builtins, they will be the low level detail you can build an evented io with.
new Io is an abstraction over the higher level details that are common between sync, threaded, and evented, so you shouldn't expect the suspension mechanism to be in it.
I mean I guess I could... But threads are pretty heavyweight. Though there may be a more lightweight way of implementing them in kernel mode (not coroutines or fibers, but actual threads) and I just have never heard of it.
