Peter Maydell <peter.mayd...@linaro.org> writes: > On 13 March 2013 12:34, Anthony Liguori <anth...@codemonkey.ws> wrote: >> AioContext is necessary for the block layer because the block layer >> still has synchronous I/O. I think we should aim to replace all sync >> I/O in the long term with coroutine based I/O. > > I think coroutines are dreadful and we should really not be moving > towards greater use of them. They're just really really not portable > and they don't fit with the C language, and they're a constant source > of problems.(For instance I have a bug I need to look into where we > seem to hang using the gthread coroutine backend but not sigaltstack.) > > Use threads, or a genuinely asynchronous API, or a select/poll loop > with callbacks, but not more coroutines please.
I disagree. Coroutines are a perfectly pedestrian control flow construct. Stefan already explained why we use them, and why callbacks are not a viable alternative when things get hairy. Coroutines fit about as well with C as threads, namely not really. Unfortunate, but switching to threads won't improve that aspect one bit, just add "interesting" concurrency and performance problems to the mix. If portable coroutines in C really was an intractable problem, the solution could not be "no more coroutines, please", only "no coroutines, period". As long as we have to pay the price for coroutines anyway, I can't see why we should deny ourselves the benefits. C programs have been doing coroutines since forever, using either hand coded assembly language stack switching, sigaltstack() trickery, ucontext(), w32 fibers, or some coroutine library built on top of these. We chose "all of the above" (except for assembly). No wonder we got more problems. Some of our portability problems come from our heroic (quixotic?) quest to keep QEMU portable to the widest range of hosts, without sacrificing performance on any of them. Sometimes it takes a tough man to make a tender chicken.
