Re: [PATCH 0/2] thread: add lock guard macros

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Wed, Mar 11, 2020 at 04:06:02PM +0100, Paolo Bonzini wrote:
> Il mer 11 mar 2020, 15:50 Markus Armbruster <armbru@redhat.com> ha scritto:
> 
> > Stefan Hajnoczi <stefanha@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]