[PATCH 03/43] conf: nwfilter_ipaddrmap: convert virMutex to GMutex
r4f4rfs at gmail.com
Sat Apr 11 18:15:15 UTC 2020
On Fri, Apr 10, 2020 at 7:06 PM Laine Stump <laine at laine.org> wrote:
> > Beyond that, why not just use the G_*() macros for *all* locks in
> > libvirt instead of only using them in cases of static locks? It seems
> > strange to use the convenience macros in some cases and the raw
> > functions in others. (I'm looking at this with 0 experience using the
> > Glib locks, so maybe there's something basic I'm just not aware of -
> > maybe something necessary is missing from the G_LOCK() macros?).
> Okay, I already see that the G_LOCK macros don't cover everything - no
> recursive mutexes and no RW mutexes for example. Too bad - it would be
> good to be consistent.
Yes, that's one issue. Another is: how do you use those macros with
locks inside structs? You can't do `G_LOCK(obj->parent.lock)` because
it'll result in `g_mutex_lock(&g__obj->parent.lock_lock)` which is
wrong. You'd have to use the raw function
`g_mutex_lock(obj->parent.LOCK_NAME(lock))` anyway, which imho, is
even worse than `g_mutex_lock(&obj->parent.lock)`. The same issue
happens when using mutexes with conditions: `g_cond_wait(cond,
` instead of just `g_cond_wait(cond, obj->parent.lock)`. So they work
better for statically-defined locks
I don't mind doing whichever you guys prefer, just let me know.
More information about the libvir-list