8:09 a.m.
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(-)
1:23 p.m.
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 :|
1:50 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
6:45 a.m.
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(a)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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
8:21 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5902
days inactive
5903
days old
4 comments
3 participants
participants (3)
-
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard