[libvirt] [PATCH v2 0/3] driver level connection close event

nshirokovskiy at virtuozzo.com nshirokovskiy at virtuozzo.com
Thu Jun 25 11:31:40 UTC 2015


Notify of connection close event from parallels driver (possibly) wrapped in
the remote driver.

Changes from v1:
1. fix comment style issues
2. remove spurious whitespaces
3. move rpc related part from vz patch to second(rpc) patch
4. remove unnecessary locks for immutable closeCallback in first patch.

Discussion.

In 1 and 2 patch we forced to some decisions because we don't have a weak
reference mechanics.

1 patch.
-----------
virConnectCloseCallback is introduced because we can not reference the
connection object itself when setting a network layer callback because of how
connection close works.

A connection close procedure is next:
1. client closes connection
2. a this point nobody else referencing a connection and it is disposed
3. connection dispose unreferencing network connection
4. network connection disposes

Thus if we referece a connection in network close callback we never get step 2.
virConnectCloseCallback broke this cycle but at cost that clients MUST
unregister explicitly before closing connection. This is not good as this
unregistration is not really neaded. Client is not telling that it does not
want to receive events anymore but rather forced to obey some
implementation-driven rules.

2 patch.
-----------
We impose requirements on driver implementations which is fragile. Moreover we
again need to make explicit unregistrations. Implementation of domain events
illustrates this point. remoteDispatchConnectDomainEventRegister does not
reference NetClient and makes unregistration before NetClient is disposed but
drivers do not meet the formulated requirements. Object event system release
lock before delivering event for re-entrance purposes.

Shortly we have 2 undesired consequences here.
1. Mandatory unregistration.
2. Imposing multi-threading requirements.

Introduction of weak pointers could free us from these artifacts. Next weak
reference workflow illustrates this.

1. Take weak reference on object of interest before passing to party. This
   doesn't break disposing mechanics as weak eference does not prevent from
disposing object. Object is disposed but memory is not freed yet if there are
weak references.

2. When callback is called we are safe to check if pointer dangling as we make
   a weak reference before.

3. Release weak reference and this trigger memory freeing if there are no more
   weak references.

 daemon/libvirtd.h            |    1 +
 daemon/remote.c              |   86 +++++++++++++++++++++++++++++++
 src/datatypes.c              |  115 +++++++++++++++++++++++++++++++----------
 src/datatypes.h              |   21 ++++++--
 src/driver-hypervisor.h      |   12 ++++
 src/libvirt-host.c           |   77 +++++++++-------------------
 src/remote/remote_driver.c   |  106 +++++++++++++++++++++++++++++---------
 src/remote/remote_protocol.x |   24 ++++++++-
 src/remote_protocol-structs  |    6 ++
 src/vz/vz_driver.c           |   26 +++++++++
 src/vz/vz_sdk.c              |   29 +++++++++++
 src/vz/vz_utils.h            |    3 +




More information about the libvir-list mailing list