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

[Stefan Hajnoczi]

On Tue, Mar 15, 2022 at 03:50:26PM +0100, Kevin Wolf wrote:
> Am 15.03.2022 um 15:05 hat Stefan Hajnoczi geschrieben:
> > On Mon, Mar 14, 2022 at 05:21:22PM +0100, Paolo Bonzini wrote:
> > > On 3/14/22 15:07, Stefan Hajnoczi wrote:
> > > > If we can reach a consensus about C++ language usage in QEMU then I'm in
> > > > favor of using C++ coroutines. It's probably not realistic to think we
> > > > can limit C++ language usage to just coroutines forever. Someone finds
> > > > another C++ feature they absolutely need and over time the codebase
> > > > becomes C++ - with both its advantages and disadvantages.
> > > > 
> > > > [...] although you can write C in C++, it's not idiomatic modern C++.
> > > > The language lends itself to a different style of programming that
> > > > some will embrace while others will not.
> > > 
> > > Yes, this is an important aspect to discuss.  I think coroutines provide a
> > > good blueprint for how QEMU might use C++.
> > > 
> > > I totally agree that, if we go this way, the genie is out of the bottle 
> > > and
> > > other uses of C++ will pop up with 100% probability.  But the important
> > > thing to note is that our dialect of C is already not standard C, and that
> > > some of our or GLib's "innovations" are actually based on experience with
> > > C++.  We can keep on writing "QEMU's C" if we think of C++ as a 
> > > supercharged
> > > way of writing these quality-of-life improvements that we already write.  
> > > In
> > > some sense coroutines are an extreme example of this idea.
> > > 
> > > In fact, a C API would have to remain unless all source files are changed 
> > > to
> > > C++, so QEMU would remain mostly a C project with C idioms, but that 
> > > doesn't
> > > prevent _abstracting_ the use of C++ features (written in modern, 
> > > idiomatic
> > > C++) behind an API that C programmers have no problems learning.  Again,
> > > coroutines are an example of this of keeping the familiar 
> > > create/enter/yield
> > > API and hiding the "magic" of C++ coroutines (and when they don't, that 
> > > had
> > > better be an improvement).
> > > 
> > > In the end, C++ is a tool that you can use if it leads to better code. For
> > > example, I don't see much use of C++ for devices for example, and the
> > > storage devices in particular do not even need coroutines because they use
> > > the callback-based interface.  But perhaps someone will try to use 
> > > templates
> > > to replace repeated inclusion (which is common in hw/display) and others
> > > will follow suit.  Or perhaps not.
> > > 
> > > One example that was brought up on IRC is type-safe operations on things
> > > such as hwaddr (i.e. hwaddr+int is allowed but hwaddr-hwaddr gives back an
> > > int64_t and might even check for overflow).  These would be opt in (you 
> > > get
> > > them just by changing a file from .c to .cc), but the actual C++ code 
> > > would
> > > still look very much like C code that uses hwaddr with no type checking.
> > > All the operator overloading gunk would be in include/.
> > > 
> > > A different topic is what would happen if all of QEMU could be compiled as
> > > C++, and could inform our selection of C++ idioms even long before we get
> > > there.  For example, I'm fine with GLib and our type-safe intrusive lists,
> > > so I don't have much interest in STL containers and I would prefer _not_ 
> > > to
> > > use STL containers even in .cc files[1].  However, perhaps QEMU's 
> > > home-grown
> > > lock guard might be replaced by something that uses C++ destructors 
> > > instead
> > > of g_autoptr, so perhaps we should consider using std::lock_guard<>, or
> > > something like that, instead of QEMU_LOCK_GUARD.  It may be interesting to
> > > pass down lock_guards as arguments to enforce "this lock is taken"
> > > invariants.
> > > 
> > > But really, coroutines would be enough work so my dish would be full for
> > > some time and I wouldn't really have time to look at any of this. :)
> > 
> > I think it will be necessary to compile QEMU with a C++ compiler quite
> > soon. It is possible to provide C APIs like in the case of coroutines,
> > but sometimes C++ features need to be exposed to the caller (like the
> > lock guards you mentioned).
> 
> I'm not sure what the C++ lock guards offer that our current lock guards
> don't? Passing down lock guards makes sense to me, but why can't you do
> that with QemuLockable? (Hm, or can the C++ version somehow check at
> compile time that it's the _right_ lock that is held rather than just
> any lock? It didn't look like it at the first sight.)
> 
> But I do see the benefit of a compiler checked CoroutineFn<> return type
> compared to the coroutine_fn markers we have today. On the other hand...

Sorry, I made a mistake: the C++ coroutines implementation does not hide
everything behind a C API. Coroutine functions need to be defined in C++
source units.

Stefan

signature.asc
Description: PGP signature