Re: [PATCH 03/43] conf: nwfilter_ipaddrmap: convert virMutex to GMutex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux