[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