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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list