On Wed, Mar 06, 2013 at 04:41:01PM +0100, Kevin Wolf wrote: > Am 06.03.2013 um 15:53 hat Stefan Hajnoczi geschrieben: > > CoQueue uses a BH to awake coroutines that were made ready to run again > > using qemu_co_queue_next() or qemu_co_queue_restart_all(). The BH > > currently runs in the iothread AioContext and would break coroutines > > that run in a different AioContext. > > > > This is a slightly tricky problem because the lifetime of the BH exceeds > > that of the CoQueue. This means coroutines can be awoken after CoQueue > > itself has been freed. > > Does this really happen in practice? If so, that sounds like a bug to > me.
I didn't audit the callers. It seems reasonable that a CoQueue is allowed to go out of scope once qemu_co_queue_empty() returns true. I don't see what is buggy about that. > > Finally, I don't want to move unlock_queue and unlock_bh into > > AioContext. That would break encapsulation - AioContext isn't supposed > > to know about CoQueue. > > So what you would need here is "AioContext local storage". I wonder if > this will stay a requirement unique to CoQueues when AioContexts gain > wider use. I'm not convinced we need AioContext local storage. We could go all the way and make AioContext* thread-local. Then we can figure out the current AioContext* or NULL, if none, at any location in the code. Then CoQueue (and others?) could attach their resources to AioContext local storage. But let's avoid it if there are clean solutions because implicit state like globals or thread-locals makes code harder to understand. Stefan
