On Tue, Apr 03, 2018 at 02:05 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
On Tue, Apr 03, 2018 at 01:46:13PM +0200, Marc Hartmayer wrote:
On Wed, Mar 21, 2018 at 07:57 AM +0100, Marc Hartmayer <mhartmay@linux.vnet.ibm.com> wrote:
On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
On Thu, Mar 08, 2018 at 01:20:25PM +0100, Marc Hartmayer wrote:
Don't assume that the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK is available for every driver used for the connection.
The very definition of the virConnectRegisterCloseCallback() API is that it will always succeed. What varies is that some driver connections may never fail and so the close callback will never be invoked. The actual registration of the callback will always succeed regardless of which driver is in use. So it is correct to report the VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK as always supported regardless of driver.
Okay. So how can we deal with the situation in patch 18 if we cannot differentiate between 'callback was “really” registered' and only the call was 'successful'? If it’s not really registered nobody will free the callback data. This was also the cause for the fix: ce35122cfe: "daemon: fixup refcounting in close callback handling".
Thanks in advance.
Polite ping.
If conn->driver->connectRegisterCloseCallback is NULL, then the virConnectRegisterCloseCallback() method should immediately call freecb(opaque).
Thanks! I’ll send a v2.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294