On Mon, Jul 13, 2026, 12:38 Irtaza Hyder <[email protected]> wrote:
> Hi there, I was reviewing the coroutine blogpost ( > https://blog.vmsplice.net/2014/01/coroutines-in-qemu-basics.html) and had > a few questions about the example given. It states in the blog that it > makes the code sequential, but aren't the co_* requests in `void > coroutine_fn say_hello` seperate callbacks we need to implement, still > leading to callback hell? > No, say_hello() is a single function. You read its code sequentially and there are no explicit callbacks, just say_hello(). > Moreover it is stated that coroutines have to be explicitly yielded or > terminated. In the example we are using blocking functions (send and > readline), so how are we defining explicit yielding in such functions? > Any function that is declared with coroutine_fn may yield and must be called from a coroutine. co_send() and co_receive() can yield but they do not block the current thread (e.g. by sitting in a blocking system call that is waiting for a single thing to happen at the expense of other coroutines being unable to run). For example let's say I am waiting on a data being to a Chardev Frontend, > perform some operation on it and then respond to the Frontend when I am > able to write, how would I write a qemu_coroutine to deal with this? Are > coroutines even the right approach to use for such a flow? > I'm not able to respond in full right now, but have CCed Daniel Berrange, who worked on the QIOChannel APIs. If you search the codebase your can find coroutine users of QIOChannel that do something similar to what you described. QIOChannel is lower level than chardev and I haven't had time to check if chardevs are used by coroutines somewhere in the codebase, sorry. > Stefan
