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