On 13.10.2016 18:04, Martin Kletzander wrote: > On Wed, Oct 12, 2016 at 04:00:52PM -0400, Dawid Zamirski wrote: >> 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? >> > > I just now realized you said the issue we are talking about crashes the > libvirt daemon, right? And it does not use virStateDriver? That's > weird. You are connecting to vbox:///session, but the crash happens in > the libvirt daemon. That means we switched the vbox driver to the > daemo-side driver, so I'd expect it to be stateful driver. Yes, couple of drivers were switched to server side drivers because of some licensing nonsense. > However it > doesn't use virStateDriver. That's because vbox is stateless driver. Just like esx for instance. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list