On Fri, Apr 10, 2020 at 7:06 PM Laine Stump <laine@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