Am 29.06.2012 02:50, schrieb Peter Crosthwaite:
>>
>> The problem I see is:
>>
>> FDTMachineInfo *fdt_generic_create_machine()
>> {
>> ...
>> while (qemu_co_queue_enter_next(fdti->cq));
>> }
>>
>> The problem you have is not that the block layer is yielding. The
>> problem is that you need to run aio processing
>
> And this is what Im trying to say is wrong. My usage of coroutine has
> nothing to do with block, AIO or any other existing client of
> coroutine. I shouldnt have to make API calls into things I dont care
> about just to make my coroutines work. The QOM people should be able
> to come along and rewrite the AIO subsystem tommorow and it shouldnt
> affect my coroutines.
This isn't really block or AIO specific. What you need to run is
basically a nested main loop. As long as you process the
(aio_)fd_handlers and bottom halves, the block layer will work.
qemu_aio_wait() implements such a nested main loop. I think the only
major thing that is not executed in qemu_aio_wait() is timers (and maybe
that's something we should change).
> Maybe I need to generalise away from block. This problem goes a level
> higher to AIO. AIO is assuming it owns all coroutines - I.E. if you
> are in coroutines context (qemu_in_coroutine()) then that coroutine
> can be pre-emented and queued up in AIO's work queue. Im saying this
> is flawed - because it means coroutines are not generic, they are for
> AIO use only.
>
> So change subject to "Remove assumption that AIO owns coroutines".
No, the assumption is a completely different one and it has nothing to
do with who "owns" a coroutine. It is about whether you may assume that
a call into a different subsystem doesn't yield. The answer today is no,
the other subsystem may yield. You want to change it to yes. But there's
nothing AIO or block specific about it.
Kevin
