It's not that elegant. Win32 fibers can't return like UNIX/ucontext.h supports with the uc_link member. So you end up having to wrap your win32 fiber function

It's not that elegant. Win32 fibers can't return like UNIX/ucontext.h supports with the uc_link member. So you end up having to wrap your win32 fiber functions with your own trampoline to let them return without exiting the program and Do The Right Thing. Furthermore there's this thread-global fibers-enabled state win32 toggles with ConvertThreadToFiber() requiring any transparent coroutines library supporting win32 fibers to carefully initialize once per thread while also supporting reentrant use. It's mildly annoying when you want to generically support things like nested bundles or heirarchies of coroutines. This last bit seems completely strange considering a fiber's state should be a subset of what forms a thread, and you're always running on a thread. There should be nothing to do when "converting" to a fiber. Just make the fiber state always accessible to userspace via GetCurrentFiber() and always allow calling CreateFiber() and SwitchToFiber(). Another strange wart in win32 fibers is the C srand()/rand() state is per-fiber for some reason. It's undefined by C since C says nothing of coroutines, but it's very strange and generally unexpected behavior to see your coroutines producing identical sequences of values coming out of rand(). On *NIX the rand() state is per-process, pthreads share user memory so they all share the rand() state, and ucontext shares the thread so of course its contexts share the single state as well. I much prefer the UNIX/ucontext API, they just fucked up the operands for makecontext(). Instead of deprecating ucontext POSIX should have just fixed makecontext() to explicitly take a pointer. C programs have no supported system-supplied coroutine API on UNIX now, which is bullshit.