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.