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

Nikolay Shirokovskiy nshirokovskiy at parallels.com
Thu Jul 16 10:42:33 UTC 2015


Guys, please take a look.

On 25.06.2015 14:31, nshirokovskiy at virtuozzo.com wrote:
> 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 +
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 




More information about the libvir-list mailing list