Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption

[Markus Armbruster]

Peter Crosthwaite <address@hidden> writes:

> On Jun 29, 2012 6:24 PM, "Kevin Wolf" <address@hidden> wrote:
>>
>> 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.

Exactly.

>>                                                  The answer today is no,
>> the other subsystem may yield. You want to change it to yes.
>
> Then can we change it to yes? If subsystems yield coroutines without checks
> then PMM is right, coroutines are just obfuiscated threads...

Unlike threads, coroutines can yield only at designated points.  That's
a fundamental difference.  Even if you had to assume every single
function in every single API may yield.

Whether the set of yield points we have now is convenient for your
application is a fair question.  But it's a "have we gotten the set of
points right" question, no less, no more.  Unless no usable set can
exist, it's not a "does the coroutine concept make sense" question.

I appreciate contributions to APIs with more useful yield semantics, and
reports on problems with current APIs do count there.  I don't mind the
occasional philosophical musings on the merits of control structures
(which is what a coroutine is).  Just keep in mind that musings are
awfully prone to distract from real work, such as helping you with your
actual problem :)