<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38"> <TITLE>RE: [libvirt] [RFC] domain-events-python</TITLE> </HEAD> <BODY>  One issue that I seem to be running into for both dom, and conn objects is the creation of a python object from the C vir{Connect,Domain}Ptr The issue is that when creating a python object, and passing "_obj" into the constructor - it will give a different python object each time, instead of searching for an existing object, and bumping the ref count. For example - each time the C callback would be called, we would create a new python object with the came "._o", rather than getting a new reference to a common one This is not an issue unless we want to store data in the python object independent from C object (like the python callback list) So...we could create a hash/dict object of virConnect objects...but when would you know to delete the last reference? -----Original Message----- From: Daniel Veillard [<A HREF="mailto:veillard@redhat.com">mailto:veillard@redhat.com</A>] Sent: Wed 10/29/2008 2:50 AM To: Daniel P. Berrange Cc: Ben Guthro; libvir-list@redhat.com Subject: Re: [libvirt] [RFC] domain-events-python On Tue, Oct 28, 2008 at 06:23:20PM +0000, Daniel P. Berrange wrote: > On Tue, Oct 28, 2008 at 09:09:53AM -0400, Ben Guthro wrote: > > Attached is a preliminary patch implementing the python bindings for > > domain events, and the EventImpl code. > > > > This implements a python test app equivalent to the code in the C > > event-test app. Contrary to what Daniel B originally suggested, I thought > > that the EventImpl would be useful to expose for apps that are strictly > > using python, and not integrating with glib, or another event loop. It > > also makes the test case easier to debug. > > That's a good idea - does make it easier to debug. yes +1 definitely > > I have not marked this with [PATCH] in the subject, as I don't believe > > it is quite complete. > > > > I am still having a few issues with the Refcounting in the C code, and > > I think there is still some cleanup code I haven't quite handled quite > > right. > > > > That said - I would welcome some comments/suggestions on this thus far, > > to make sure I'm not going off in a direction contrary to where you > > think I should be. > > I think my main thought would be to try and domore of the event > dispatch work in the python layer, rather than C layer. So rather > than doing the de-multiplexing to all registered callbacks in > libvirt_virConnectDomainEventCallback, have that C method call > into a python virConnectDomainEventCallback function, and have > that de-multiplex the events out to all application callbacks. > I think it'd probably make the code a little easier to follow, > and might simplify the ref counting problems. > > Likewise I think I'd also keep more of the 'DomainEventRegister' and > 'Unregister' impl in the python layer. Perhaps keeping the list of > callbacks as an attribute in the 'class virConnect', rather than the > static global variable pyobj_domain_event_cbs. Agreed too, since we don't care too much about performances in that code it is really easier to implement and debug if most of the logic is done in Python rather than C. The reference counting problem in callback based interfaces can be nasty as I found out in libxml2, that too can be simplified greatly by doing most of the work on the python side. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit <A HREF="http://xmlsoft.org/">http://xmlsoft.org/</A> daniel@veillard.com | Rpmfind RPM search engine <A HREF="http://rpmfind.net/">http://rpmfind.net/</A> <A HREF="http://veillard.com/">http://veillard.com/</A> | virtualization library <A HREF="http://libvirt.org/">http://libvirt.org/</A> </BODY> </HTML>