On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite <peter.crosthwa...@petalogix.com> wrote: > BTW Yielding is one thing, but the elephant in the room here is > resumption of the coroutine. When AIO yields my coroutine I i need to > talk to AIO to get it unyielded (Stefans propsoed edit to my code). > What happens when tommorow something in QOM, or a device model or is > implemented with coros too? how do I know who yielded my routines and > what API to call re-enter it?
Going back to what Kevin said, the qemu_aio_wait() isn't block layer specific and there will never be a requirement to call any other magic functions. QEMU is event-driven and you must pump events. If you call into another subsystem, be prepared to pump events so that I/O can make progress. It's an assumption that is so central to QEMU architecture that I don't see it as a problem. Once the main loop is running then the event loop is taken care of for you. But during startup you're in a different environment and need to pump events yourself. If we drop bdrv_read()/bdrv_write() this won't change. You'll have to call bdrv_co_readv()/bdrv_co_writev() and pump events. Stefan
