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