On Fri, Apr 10, 2020 at 7:01 PM Laine Stump <laine@xxxxxxxxx> wrote: > > On 4/10/20 9:54 AM, Rafael Fonseca wrote: > > Signed-off-by: Rafael Fonseca <r4f4rfs@xxxxxxxxx> > > --- > > src/conf/nwfilter_ipaddrmap.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/src/conf/nwfilter_ipaddrmap.c b/src/conf/nwfilter_ipaddrmap.c > > index 672a58be3a..3c1927f9ff 100644 > > --- a/src/conf/nwfilter_ipaddrmap.c > > +++ b/src/conf/nwfilter_ipaddrmap.c > > @@ -32,7 +32,7 @@ > > > > #define VIR_FROM_THIS VIR_FROM_NWFILTER > > > > -static virMutex ipAddressMapLock = VIR_MUTEX_INITIALIZER; > > +G_LOCK_DEFINE_STATIC(ipAddressMapLock); > > The documentation for the G_LOCK() macros says that the name provided in > the args will be mangled, so you can just use the same name as the > object you're going to lock, e.g.: > > > G_LOCK_DEFINE_STATIC(ipAddressMap); > > > instead of "ipAddressMapLock". The upside is that's less typing, and if > you do a keyword search you'll find all the places where ipAddressMap is > locked/unlocked along with its uses. The downside would be that you > couldn't as easily do a keyword search for just the lock manipulation > (you'd need to use a regex to search for "G_.*ipAddressMap" or something > like that); I still kind of like the idea of using the exact same name, > just because it encourages consistency. Ok I can do that. Att. -- Rafael Fonseca
