Am 22.06.2012 10:16, schrieb Peter Maydell: > On 22 June 2012 09:00, Peter Crosthwaite > <peter.crosthwa...@petalogix.com> wrote: >> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >>> Not sure if I understood the intention yet: Is this supposed to fix an >>> issue with the current usage of coroutines or to extend their usage >>> beyond that? In the latter case, please don't do this. We'd rather like >>> to get rid of them long term. > >> My extended usage, which is under development and not ready for the >> list. But are you saying qemu-coroutine is deprecated? If so Ill just >> re-impelement my work with threads, mutexes and condition vars, but >> coroutines are the most natural way of doing it. > > Basically coroutines are nastily unportable and we've had a set > of problems with them (as witness the fact that we have three > separate backend implementations!). There is supposedly some sort > of migration plan for getting them out of the block layer eventually; > they're a kind of halfway house for avoiding synchronous I/O there > AIUI. I would much prefer not to see any further use of them in new > code. Fundamentally C doesn't support coroutines and it's much better > to just admit that IMHO and use more idiomatic design approaches > instead.
Our default coroutine implementation isn't really as portable as we wish, but while we use this in order to achieve the best performance, long term we could make gthread the default backend and keep coroutines where they are useful. The gthread backend is slower than the ucontext/sigaltstack ones, but it shouldn't make a difference in performance compared to using threads and putting exactly the same locking in place open-coded like Peter mentioned as an alternative approach. Kevin
