I think the best way is to let libvirt to catch the abnormal exit signal
for the application. A default signal handler in libvirt will
un-register the event before the application exists abnormally.
On 2011-12-2 18:52, ShaoHe Feng wrote:
Hi Eric,
There's a question about register an Event.
When user starts an application call
remoteDispatchDomainEventsRegisterAny to register an event.
And for some reasons, this application breaks down.
Will the libvirtd daemon know the application breaks down? And delete
the event?
if not, then user restarts this application, it will register an event
again.
but the libvirtd daemon has already register this event, so it return error.
and then application did not know why this fails, And it will not
register this event again.
is this right?
, Eric Blake wrote:
On 10/13/2011 08:53 PM, shu ming wrote:
Also I think it would be better if we were able to connect to explicit
JSON
events, rather than a catch all. THe number of events from QEMU is only
going to increase over time& as it does, a 'catch all' becomes
increasingly
bandwidth wasteful.
If I understand correctly, the idea behind these functions is: the
application developers know there is a new QEMU event not known by
libvirt library yet.
And the developer still requests to add a callback for the new event
without the upgrade of libvirt . The functions above provide a QEMU
specific way to
let the application register the callback by QEMU event without much
intervention of libvirt. Then later if we want to promote the QEMU
specific way to the libvirt,
we should warn the application developer that the QEMU specific way is
obsolete.
Yes. Whether or not the qemu registration continues to work after the
official libvirt event is added is a different matter, since we've
already documented that use of libvirt-qemu is unsupported, but if it
is possible to cheaply provide the event through both means, then
doing that will allow more clients using the older libvirt-qemu to
continue working without recompiling to use the newer libvirt event.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
Shu Ming<shuming@xxxxxxxxxxxxxxxxxx>
IBM China Systems and Technology Laboratory
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list