[libvirt] [PATCH 1/3] Domain events - primary implementation
Ben Guthro
bguthro at virtualiron.com
Wed Oct 15 20:26:40 UTC 2008
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.
More information about the libvir-list
mailing list