[tptacek]

Most network programs spend much of their entire life waiting for IO events.

I have no argument in principle for the idea that you should restructure your whole program's control flow with transparent cooperative scheduling to attempt to get the best of both worlds of straight-line coding and efficient scheduling, except that it feels to me like you're kind of not really even writing C code anymore at that point. This might be irrational of me.

In the meantime, if you're not going to adopt an exotic thread scheduling library, I think events are the way to go. POSIX threads don't make much sense to me.

[SamReidHughes]

Development using coroutine libraries goes much faster and the resulting code is much more robust than that which uses events and callbacks. This is even more strongly the case in C++ where you can take advantage of traditional C++ RAII on any coroutine stack, which you couldn't do so nicely and clearly with callbacks. In the ten months since we started using them, we've had no stability problems and no strange and inscrutable bugs from within our coroutine implementation. There have been user errors from misuse of coroutines, but nothing anywhere near the order of magnitude of what you get when using callbacks.

[p9idf]

"I have no argument in principle for the idea that you should restructure your whole program's control flow with transparent cooperative scheduling"

Maintaining any kind of long-term state for the functions which the event loop calls can be trickier than it needs to be, since they need to quickly return and can't leave anything on their stack.