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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list