Guys, please take a look. On 25.06.2015 14:31, nshirokovskiy@xxxxxxxxxxxxx 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list