On Wed, Jun 27, 2012 at 4:05 AM, Peter Crosthwaite <peter.crosthwa...@petalogix.com> wrote: > I still think this thread points out a major flaw in block+coroutines, > regardless of the fact im using it from a machine model. This bug is > going to happen in any coroutine code that touches the block layer > (E.G. what happens if the next developer wants to implement a device > using coroutines?). Yes, without my full series there is no bug today, > but im just trying to save the next developer who decides to use > corourites (whether that be in tree or out of tree) the potentially > several hours of debugging around "why did my coroutine get yielded > randomly". That and of course minimisation of my own mainline diff.
The if (qemu_is_coroutine()) "fastpath" taken by the block layer today hopefully won't be around forever. It's really a shortcut that allows code originally written with synchronous I/O in mind to work unmodified in a coroutine. Really we should get rid of bdrv_read() and friends so that all callers use either bdrv_aio_*() or bdrv_co_*(). Then all functions that yield will be marked coroutine_fn. Then you know for sure that the function may yield and you cannot rely on it not yielding. I'd like to see your code though because I still don't understand why it relies on the exact yield behavior. Have you pushed it to a public git repo? Stefan
