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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 14, 2022 at 10:31:47AM +0100, Paolo Bonzini wrote:
> However, there  are no ramifications to actual coroutine code, except
> for the template syntax "CoroutineFn<return_type>" for the function and
> the mandatory co_await/co_return keywords... both of which are an
> improvement, really: the fact that a single function cannot run either
> inside or outside coroutines is checked by the compiler now, because
> qemu_coroutine_create accepts a function that returns CoroutineFn<void>.
> Therefore I had to disable some more code in util/ and qapi/ that used
> qemu_in_coroutine() or coroutine_fn.

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.

In general it is possible to call C++ functions from C.

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.

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

This leads me to wonder if we can workaround this problem with
a wrapper function. eg in a io/channel.hpp file can be declare
something like:

  CoroutineFn<void> qio_channel_yield_impl(QIOChannel *ioc,
                                           GIOCondition condition);

  extern "C" {
    static inline void qio_chanel_yield(QIOChannel *ioc,
                                        GIOCondition condition) {
      qio_channel_yield_impl(ioc, condition)
    }
  }

With this qio_channel_yield_impl and qio_channel_yield are both
compiled as C++, but qio_channel_yield is exposed with C linkage
semantics. Thus enabling callers of qio_channel_yield can carry
on being compiled as C, since the invokation of the CoroutineFn
is in the inline C++ function ?

This would mean an extra function call, but perhaps this gets
optimized away, espeically with LTO, such that it doesn't impact
performance negatively ?

The impl of qio_channel_yield_impl() could also call from C++
back to C functions as much as possible.

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 ?

With Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|