Re: [PATCH experiment 00/16] C++20 coroutine backend

[Paolo Bonzini <pbonzini@redhat.com>]

On 3/15/22 17:15, Daniel P. Berrangé wrote:
> Bear with me as I suggest something potentially/probably silly
> given my limited knowledge of C++ coroutines.
> 
> Given a function I know about:
> 
>    void coroutine_fn qio_channel_yield(QIOChannel *ioc,
>                                        GIOCondition condition);
> 
> IIUC, you previously indicated that the header file declaration,
> the implementation and any callers of this would need to be in
> C++ source files.
> 
> The caller is what I'm most curious about, because I feel that
> is where the big ripple effects come into play that cause large
> parts of QEMU to become C++ code. [...]
> I presume there is something special about the CoroutineFn<void>
> prototype preventing that from working as needed, thus requiring
> the caller to be compiled as C++ ? IIUC compiling as C++ though
> is not neccessarily the same as using C++ linkage.

Yes, the CoroutineFn<void> function must either be passed to 
qemu_coroutine_create() or called as "co_await f()".  If you call it as 
"f()" it does nothing except leak the memory needed by its stack frame, 
so that only leaves passing the function to qemu_coroutine_create().

I suppose you could do some games with typedefs, like

#ifdef __cplusplus
typedef CoroutineFn<void> VoidCoroutine
#else
typedef struct VoidCoroutine VoidCoroutine;
#endif

to be able to declare a function that returns CoroutineFn<void> but I'm 
not sure of the advantage.

> So I'm assuming the caller as C++ requirement is not recursive,
> otherwise it would immediately mean all of QEMU needs to be C++.

Right, qemu_coroutine_create() must be called from C++ but the caller of 
qemu_coroutine_create() can be extern "C".  In the particular case of 
the block layer, callers of qemu_coroutine_create() include 
callback-based functions such as bdrv_aio_readv(), and synchronous 
functions such as bdrv_flush().  Both of these can be called from C.

> IOW, can we get it such that the C++ bit is just a thin shim
> "C -> C++ wrapper -> C++ CoroutineFn -> C", enabling all the
> C++ bits to be well encapsulated and thus prevent arbitrary
> usage of C++ features leaking all across the codebase ?

No, unfortunately not.  But in particular, even though the block layer 
would be C++, device models that use it would not.

Paolo