[bobinator606]

programs that use lots of signals and/or asynchronous completion of IO or timers ("completions")

completions create all sorts of concurrency problems because they are delivered to the program without any concurrency protection, and writing such protection correctly turns out to be non-trivial.

By delivering completions into coroutines, you gain all the concurrency protection that is offered by the green threads, without having to write it from scratch.

[zzzcpan]

> programs that use lots of signals and/or asynchronous completion of IO or timers ("completions")

This is actually what the most basic event loop handles for you. OS signals, timers and asynchronous events are not delivered into the middle of your program, but into the point, where all of the event handlers are not running. That's the beauty of it. You can then react to the event and cancel whatever you are waiting to be running, or schedule something new.

With coroutines you can only safely handle those things each in a separate coroutine. But you don't need them isolated, you need your code to actually do something on those signals and timer events. So, you end up with a lot of flags spread all over other coroutines, protected by mutexes/channels. But then it's still not responsive, because you cannot unblock a currently blocking call, so many concurrency patterns do not apply and even bad things happen, like leaks and deadlocks. You rethink it again and move blocking calls each into a separate coroutine, so you would be able to construct a loop that waits for messages from other coroutines and reacts right away, abandoning blocking coroutines, if required. Hopefully you eventually realize, that you are emulating an event loop, but a very clumsy one, and go back to working with event handlers and higher-order functions.