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

[Kevin Wolf]

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

> Also, once C++ is available people will start submitting C++ patches
> simply because they are more comfortable with C++ (especially
> one-time/infrequent contributors).

...using C++ in coroutine code means that all of the block layer would
suddenly become C++ and would be most affected by this effect. I'm not
sure if that's something I would like to see, at least until there is a
clear tree-wide policy (that preferably limits it to a subset that I
understand).

Kevin

signature.asc
Description: PGP signature