[libvirt] [PATCH] Free object after *Destroy in python bindings

Daniel P. Berrange berrange at redhat.com
Tue May 20 13:16:39 UTC 2008


On Tue, May 20, 2008 at 01:20:17PM +0100, Richard W.M. Jones wrote:
> On Tue, May 20, 2008 at 12:58:15PM +0100, Daniel P. Berrange wrote:
> > On Tue, May 20, 2008 at 10:51:43AM +0100, Richard W.M. Jones wrote:
> > > On Mon, May 19, 2008 at 09:25:55PM +0100, Daniel P. Berrange wrote:
> > > > The docs are wrong. Destory merely hard-kills the object being managed.
> > > > It does not free memory associated with the object.
> > > 
> > > No, the documentation says it frees the objects (and has done
> > > forever), so it should free them.  I have code which depends on this
> > > behaviour.
> > 
> > It depends on behaviour which does *not* exist  so is already broken. With
> > inactive domains free'ing the object after destroy is non-sensical because
> > the domain still exists, merely in the shutoff state.
> 
> If 'implements correctly the documented API' is 'broken', well then ...
> 
> I looked back at an old implementation of libvirt (June '07) just to
> see what the behaviour used to be.  Note virDomainUndefine &
> virNetworkUndefine (oops!):
> 
> 			xen		qemu		test
> ----------------------------------------------------------------------
> virDomainDestroy	no		no		no
> virNetworkDestroy	no		no		no
> virDomainUndefine	no		frees		no
> virNetworkDestroy	no		no		no
> virNetworkUndefine	no		frees		no
> 
> For comparison in current CVS none of those calls free the object.

Fortunately, the QEMU driver is never invoked directly by end user apps,
only ever called via the daemon, so those broken semantics in the QEMU
driver didn't leak out into the public users.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list