On 13.10.2016 23:33, Dawid Zamirski wrote:
> On Thu, 2016-10-13 at 12:04 +0200, Martin Kletzander wrote:
>> On Wed, Oct 12, 2016 at 04:00:52PM -0400, Dawid Zamirski wrote:
>>>
>>> So after my initial attempts at handling this as suggested (create
>>> vboxDriver struct and initialize in
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
On Thu, 2016-10-13 at 12:04 +0200, Martin Kletzander wrote:
> On Wed, Oct 12, 2016 at 04:00:52PM -0400, Dawid Zamirski wrote:
> >
> > So after my initial attempts at handling this as suggested (create
> > vboxDriver struct and initialize in VIR_ONCE_GLOBAL_INIT), I've
> > stumbled upon
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,
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
On Tue, Oct 11, 2016 at 03:44:45PM -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:
>
> I don't understand how vbox works, but if
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:
> >
>
> > I don't understand how vbox works, but if initializing
> > g_pVBoxGlobalData
> > does not make any
On Tue, Oct 11, 2016 at 11:23:13AM -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:
>
> * _pfnUnitilalize decrements connectionCount in g_pVBoxGlobalData
> and
> once it is down to 0, it
On Tue, Oct 11, 2016 at 10:58:47AM -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
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:
> >
> > * _pfnUnitilalize decrements connectionCount in g_pVBoxGlobalData
> > and
> > once it is down to 0, it calls pfnComUnitialize and
> > g_pVBoxGlobalData if
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
On Wed, Sep 28, 2016 at 01:41:35PM -0400, Dawid Zamirski wrote:
Since VBOX API initialization method (pfnComInitialize) is not
thread-safe and must be called from the primary thread, calling it in
every vboxConnectOpen (as we used to do) leads to segmentation
faults when multiple connections are
Since VBOX API initialization method (pfnComInitialize) is not
thread-safe and must be called from the primary thread, calling it in
every vboxConnectOpen (as we used to do) leads to segmentation
faults when multiple connections are in use. Therefore the initalization
and unitialization logic has
13 matches
Mail list logo
