[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [RFC PATCH] coroutines: generate wrapper c
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [Qemu-devel] [Qemu-block] [RFC PATCH] coroutines: generate wrapper code |
Date: |
Mon, 11 Feb 2019 09:38:37 +0000 |
11.02.2019 6:42, Stefan Hajnoczi wrote:
> On Fri, Feb 08, 2019 at 05:11:22PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> We have a very frequent pattern of wrapping a coroutine_fn function
>> to be called from non-coroutine context:
>>
>> - create structure to pack parameters
>> - create function to call original function taking parameters from
>> struct
>> - create wrapper, which in case of non-coroutine context will
>> create a coroutine, enter it and start poll-loop.
>>
>> Here is a draft of template code + example how it can be used to drop a
>> lot of similar code.
>>
>> Hope someone like it except me)
>
> My 2 cents. Cons:
>
> * Synchronous poll loops are an anti-pattern. They block all of QEMU
> with the big mutex held. Making them easier to write is
> questionable because we should aim to have as few of these as
> possible.
Understand. Do we have a concept or a kind of target for a future to get rid of
these a lot of poll-loops? What is the right way? At least for block-layer?
>
> * Code generation makes the code easier to write but harder to read.
> Code is read more than written. In this case I think open coding
> isn't too bad and I prefer it to reading a code generation script to
> understand how it works.
But you can read generated code in same way. You only need to read generator
script if it generates something wrong, but should be rare.
>
> If we were planning to add lots more of these then I agree code
> generation would help. But in this case I'd rather not.
>
What do you think at least of generating code to create a coroutine from a
function
with multiple arguments?
--
Best regards,
Vladimir