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.


libvir-list mailing list

Reply via email to