Am 22.06.2012 10:00, schrieb Peter Crosthwaite: > On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2012-06-22 08:44, Peter A. G. Crosthwaite wrote: >>> The block layer assumes that it is the only user of coroutines - >>> The qemu_in_coroutine() is used to determine if a function is in one of the >>> block layers coroutines, which is flawed. I.E. If a client (e.g. a device or >>> a machine model) of the block layer uses couroutine itself, the block layer >>> will identify the callers coroutines as its own, and may falsely yield the >>> calling coroutine (instead of creating its own to yield). >>> >>> AFAICT, there are no conflicts in the QEMU master here yet, but its kind of >>> an >>> issue, as anyone who comes along and used coroutines and the block layer >>> together is going to run into some very obscure and hard to debug race >>> conditions. >> >> 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.
I don't think we're going to drop them as long as they are useful for someone, and definitely not anytime soon. Possibly at some point, when the block layer is converted to threads, we could make gthread the only (or the default) backend, which will impact performance a bit, but works on more platforms. Kevin
