On Wed, Mar 11, 2020 at 04:06:02PM +0100, Paolo Bonzini wrote: > Il mer 11 mar 2020, 15:50 Markus Armbruster <arm...@redhat.com> ha scritto: > > > Stefan Hajnoczi <stefa...@redhat.com> writes: > > > > > Lock guards automatically call qemu_(rec_)mutex_unlock() when returning > > from a > > > function or leaving leaving a lexical scope. This simplifies code and > > > eliminates leaks (especially in error code paths). > > > > > > This series adds lock guards for QemuMutex and QemuRecMutex. It does not > > > convert the entire tree but includes example conversions. > > > > I support the move towards automatic cleanup, but I'm wary of > > incremental conversion. Experience tells that outdated examples > > invariably get copied / imitated, with incremental conversion struggling > > to keep up. > > > > Are we resigned to having both kinds of mutex cleanup forever? > > > > There are cases where the legibility benefits of guards are debatable, or > they require more complex functionality in the guards (see my other answer > to Stefan). So, yes. We don't have that many mutexes so incremental > conversion should be doable without taking forever.
I will add this to the BiteSizedTasks wiki page when the patch is merged, together with guidelines on how to convert code (it requires case-by-case evaluation and is not a simple mechanical change). We will continue to have raw qemu_(rec_)mutex_lock/unlock() calls in cases where a complex locking scheme is used or lock guards would make the code less clear. Stefan
signature.asc
Description: PGP signature
