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.