On Fri, Apr 10, 2020 at 7:06 PM Laine Stump <laine(a)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,
obj->parent.LOCK_NAME(lock))
` 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.
Att.
--
Rafael Fonseca