Re: [libvirt] [PATCH 1/3] Domain events - primary implementation

[Ben Guthro <bguthro virtualiron com>]

I've been off implementing all of these changes, and I came across a point I 
would like to discuss, and get your opinion on.

...
> In fat I think this scheme ought to let you do away with the mutex
> locking completely. The contract for virConnectPtr dictates that
> you are forbidden to use a single virConnectPtr object from more than
> one thread at once, so if we're queueing & dispatching events from
> and timeout handler, we shouldn't ever get a reentrancy/locking 
> problem.

We potentially have a race condition for pulling data off the wire by the following functions:

call()
remoteDomainEventFired()

These 2 functions lock on not the connection lock, but the private_data->lock.

Since the remoteDomainEventFired() is called from a client app via HandleImpl - it has no
knowledge of that the opaque pointer being passed is a conn. 

There is nothing constraining the EventImpl from making a callback while using a conn ptr in another thread.

So - if that callback happens concurrent with an explicit use of the conn ptr bad things will happen.