On Mon, Aug 28, 2006 at 11:53:09PM -0400, pvetere@redhat.com wrote:
Hi all. So, I found a bug in the python bindings that I'd really like to fix, but when I sat down to do so I quickly found myself mired in a swampy mess of code generation: generator.py. :-) Now, I feel compelled to ask -- why don't we just have a static libvirt.py file that is WYSIWYG? The generator.py program alone is longer than the file it generates, and having a static file would not only make the code easier to read, but would also make bug fixing much simpler. But, I'm sure there's got to be a good reason for it. :-)
Historic, the same generator is used by libxml2 and libxslt at least.
Here's a program that produces the bug I tried to address:
import libvirt def get_domain(dom_name): conn = libvirt.openReadOnly(None) domain = conn.lookupByName(dom_name) return domain d = get_domain("mydomain") print d.info()
This is a fairly typical "factory" pattern I could imagine people using. The problem is that the connection object falls out of scope after the get_domain routine ends, and is therefore garbage collected. This leaves the "d" domain object with no valid connection, resulting in a "libvir: Xen error : failed Xen syscall ioctl 3166208" error. The simple solution would be for the connection object to pass a reference to itself into each domain object it creates. The domain objects would then maintain the reference until they are destroyed.
Hum, right, but really even at the C level you want to keep the connection around as long as you manipulate the domain.
I valiantly tried to follow the table-based patterns used in generator.py to fix this problem, but I found myself inventing somewhat arbitrary rules just to force the code I wanted it to output.
And hence, $SUBJECT. :-)
Okay, this may look surprizing, but well ... Now we can probably add a reference back from the domain to the connection, but still dropping any handle to the connection is kind of weird. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/