[libvirt] [RFC] domain-events-python
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. 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. examples/domain-events/events-python/event-test.py | 187 ++++++++ python/generator.py | 8 python/libvir.c | 454 +++++++++++++++++++++ python/libvir.py | 20 python/libvirt_wrap.h | 27 + python/types.c | 48 ++ 6 files changed, 740 insertions(+), 4 deletions(-)
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.
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. Daniel -- |: Red Hat, Engineering, London -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 :|
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 http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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 [mailto:veillard@redhat.com] 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 http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Wed, Oct 29, 2008 at 07:45:26AM -0400, Ben Guthro wrote:
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?
Yes, the .o trick cmes from libxml2 python bindings where i used the same thing. This can be a bit confusing, but as you noted we don't really found a good workaround to the refcounting problem otherwise. I guess it's fine to implement it that way, if not perfect, and if some Python guru come with a solution, well we don't expect the user code to use the ._o directly so we should be able to change the way we do the mapping without disturbing the python applications. The connection object could be stored though since the virConnectDomainEventRegister() function will need a connection, there in the python bindings we can save a reference to that object and bring it when we get an event. But for Domains, yes we will duplicate objects :-\ Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (3)
-
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard