That sounds good to me. Hope you’re not getting discouraged, and I wonder if you’re worrying too much at this point about supporting easy migration between Zig versions for your library users. Zig users are accustomed to having to wait for libraries to be updated for the latest Zig, so I don’t think waiting until a Zig version is final to do that integration is a big deal.
You’re library sounds great! I’m hoping to try it out in a couple months.
Now that 0.16 has been released, I’ve brought back the std.Io implementation. It’s not 100% done yet, some parts are missing, but networking should be fully functional, most file/dir ops should be functional and obviously the fiber-based future/group is fully functional. Works on Linux, Windows, macOS, FreeBSD, NetBSD.
Hi, first of all, great work on the zio so far.
I am not new to zio, its running one of my personal hobby projects currently, but i never really toyed with the runtime setup (except increasing worker thread count).
How is it looking with -fsingle-threaded support?
Is it possible to run zio (even without the flag set) in truly single threaded environment?
(with exact(1) it seems to run completely single threaded on simple example code, but i dont know any complexities of the Runtime, and whether the ThreadPool wont fuck it up)
When i try just “stupidly” set the flag, it seems to get stuck on the thread spawning (since zio.Runtime.init() config is runtime known and thus worker thread spawning is still analyzed).
Also smp_allocator is throwing its top level comptime check, i have absolutely no idea why its being referenced (i dont use it in my code, double checked that). Possibly one of the changes in type resolution in 0.16, or it just gets analyzed first time Thread is referenced.
This is 100% hobby scenario, I dont use zio this way and I was mostly just interested in the functionality zio currently supports.
Robert 
It’s not currently possible, I didn’t even know the option existed. 
The main useage pattern for zio is similar to asyncio or nodejs. You have one thread for the networking code and delegate blocking work to a thread pool.
For a fully single threaded mode, the strategy would have to change and it would have to block the main thread if there is no async API for a particular operation. It’s probably not a large change to support this, might be interesting for me to do it, because it would also change some other behavior (no low level locking, etc).