Re: [PATCH 3/4] vbox: change API (un)initialization logic.

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

 



On Tue, 2016-10-11 at 10:58 -0400, Dawid Zamirski wrote:
> On Tue, 2016-10-11 at 16:22 +0200, Martin Kletzander wrote:
> > On Wed, Sep 28, 2016 at 01:41:35PM -0400, Dawid Zamirski wrote:
> > 
> > The allocation is not guarded by any lock, so there's still a
> > race.  I
> > think there should be a global struct that has only some lock in it
> > and
> > whatever global data you need, the struct will be initialized on
> > the
> > first call to any function (check out VIR_ONCE_GLOBAL_INIT) and
> > then
> > the
> > connection (or global data or how it's called) would be reference
> > counted (just like you have).  It's just that having the reference
> > count
> > in the object you will be reallocating over and over again for each
> > connection is not really good.
> > 
> 
> 
> Thanks, I see, I'll address this in v2
> 

So after my initial attempts at handling this as suggested (create
vboxDriver struct and initialize in VIR_ONCE_GLOBAL_INIT), I've
stumbled upon virStateDriver structs used in other drivers that
apparently has .stateInitialize, .stateCleanup that to me look like
perfect places to call vbox's pfnComInitialize pfnComUnintialize pairs.
Would this be a good idea to utilize the virStateDriver for this or
should I stick with VIR_ONCE_GLOBAL_INIT way?

PS. Thanks a lot for reviewing my code and guiding me through it all.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[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]