On Fri, Apr 10, 2020 at 7:01 PM Laine Stump <laine@laine.org> wrote:
On 4/10/20 9:54 AM, Rafael Fonseca wrote:
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com> --- 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