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

[Peter Crosthwaite]

Can anoyne explain to me the consequences of my patch btw? I am
struggling to see how co-routines actually call into the block layer
API (without already being there) such that these fast paths are even
activated?

>>>
>>> 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,

So they way you are talking, it sounds like the set of "yield points"
is global. I think this is where it all goes pear shaped. What I am
proposing, is that for some coroutines it will be valid to yield at
A,B, C. Others, valid to yield and D, E and F, yield points should not
be considered a global thing or you end up with this viral taintage
where every function call leaving a subsystem you must assume it could
get coro yielded.

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?

no less, no more.  Unless no usable set can
> exist, it's not a "does the coroutine concept make sense" question.

Coroutines do make sense :) I wouldnt have used them otherwise. My
dispute is with the global yield point concept.

>
> 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 :)

I have plenty of workarounds to the problem and my code is not bugged
anymore, but I don't want a fragile solution to the problem. This
patch is in my tree and will suffice for me and will stay there till
this get resolved.

Regards,
Peter