Re: [Libvir] Re: Asynchronous notifications of domain start/stop
On Wed, Jul 18, 2007 at 12:30:03PM +0200, Gerd Hoffmann wrote:
Hi,
> 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 general events are a pain because the integration in the application
is never that clean or simple.
For the callback model to work you need the application to call the library
in some way (to then check the condition and do the callback), to me threading
in the library is not a good working model because then you callback from a
different thread and lot of confusion/races ensue.
> 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.
I did that trick in gamin to write to the fd within the signal to
pass the information in a safe way. Still I would really like to avoid
getting down to the same kind of crazyness. The problem is that not
everything is data down a file/pipe but that's the only way to integrate
decently in an Unix app programming model :-(
I resisted so far adding events in libvirt API precisely to keep the
level of complexity of the API down. If we go there, then an fd based
mechanism with a function called by the user to get the information has
my preference. That way except for the fd everything is synchronous and
purely within the application flow of control. The problem is how to
then feed the fd when "something occurs" especially since the something is
happening in a different process or even a different domain. I have no
clear answer to this, and until I have (and this is still sensible for
the variuous hypervisor) I would rather postpone getting there.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/