[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: Asynchronous notifications of domain start/stop


> libvirt, but requires asynch notifications of domain start/stop (and

Notification.  Not async notification.

Point is I want avoid waking up every second or so to poll for rare
events.  There is no need for the events being truly async.

> typedef int virEventHandle;
> /* Register a callback to catch domain start events. */ 
> virEventHandle virEventDomainStart (virConnectPtr, void (*f)
> (virConnectPtr, int domid));
> /* Register a callback to catch domain stop events. */ virEventHandle
> virEventDomainStop (virConnectPtr, void (*f) (virConnectPtr, int
> domid));
> /* Unregister any type of callback. */ int virEventCancel
> (virConnectPtr, virEventHandle handle);

Doesn't need to be a callback model.

> In the Xen case, we can use XenStore watches[1].  Callbacks from 
> XenStore can be translated directly into event callbacks.

xenstore doesn't calls you back.  xenstore gives you a file handle you
can select() on and a function you can call when data is available to
figure which watch did fire.

You can register a token together with the watch, which in turn you can
use to implement callbacks.  But libxenstore itself doesn't callback you.

> In the qemu/remote case, asynch notifications are nominally supported
> by the protocol, but I haven't really looked at all the implications.
> Seems like we'd need to use MSG_OOB to signal the client process, and
>  translate the SIGURG signal received into a callback.

I'd like to veto that idea.  Calling a callback from a signal handler is
just asking for trouble.  It isn't safe to call libc functions from a
signal handler for example.  Also libvirt hijacking the SIGURG signal is
not very nice.

> We would also need to avoid mixing ordinary request/response with the
>  notifications

Why?  Just disallowing notifications while a request is in flight should
be enougth I think.

I'd like to have something which integrates nicely with the usual
select() based event loops, like the xenstore model.  Sort of "here is a
file handle, and if data comes in call this function."  The function in
turn could either call callbacks or return some event struct.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]