[libvirt] [PATCH] add a default event handle, to passthough the new events come from qemu

[Shu Ming]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory