On Fri, Sep 19, 2008 at 11:08:37AM -0400, David Lively wrote: > On Fri, 2008-09-19 at 11:14 +0100, Richard W.M. Jones wrote: > > On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote: > > > I'm a little concerned that a vector of event type names isn't really > > > adequate for specifying a filter. Does this need to be more general > > > (XPathString exprs??) > > > > I think I'm with Dan on this one. I would start small -- just domains > > coming & going (unless VirtualIron needs other events). Since there > > is no limit to the number of API calls we can have in libvirt, add an > > API call just for registering for these domain events. Instead of > > trying to overload untyped strings with complicated meanings. > > Okay. I'm fine with a more strongly-typed event protocol. While it's > more work to add new classes of events (as compared with extending event > XML), that's probably a Good Thing :-) it makes processing event simpler/cheaper, and if you want to scale that's not neglectible :-0 > > > > > But my larger concern is that an asynchronous callback mechanism (as > > > proposed above) assumes the presence of some thread / process from which > > > to make the callbacks. This works fine in the libvirtd context, but > > > not outside of it. For instance, we build a "client only" version of > > > libvirt with ONLY the remote driver, which currently doesn't require > > > pthreads at all. Introducing asynchronous callbacks into the API means > > > pthreads is now required for this. > > > > I'm not quite sure I follow this -- you mean it introduces pthreads > > into libvirt or into the caller? As far as I can see, nothing about > > this would require threads in either. > > I meant that if we expected the callbacks to "just happen", libvirt (at > least, the libvirtd-less version) would need to spawn a thread to make > the callbacks. > > But this is quite easily avoided by providing a hook that clients are > responsible for calling for event delivery, as suggested. I had > considered this as an alternative to the file-descriptor interface (but > thought the fd interface was convenient with to use w/select() & > poll()). the fd registration is really not ideal, as Dan and Rich suggested the hook based solution allows cleaner code, and more portability. > After considering the problems with fds and power-saving and > windows compatibility, I agree an event-delivery hook sounds like the > best idea, perhaps: > > int virDeliverEvents(int timeout) > > where timeout is interpreted as in poll() (i.e., max millisecs to block, > 0 means don't block, negative means block forever). let's copy the kind of interface DBus provided, at least for consistency :-) > > > > The remote protocol allows event messages to be passed back > > asynchronously, although the current remote driver wouldn't expect to > > receive them which might be a problem for backwards/forwards > > compatibility. (Therefore the remote client must tell the remote > > server that it can handle asynchronous events, and the remote client > > must be prepared to talk to a server which cannot understand > > asynchronous events -- there is an internal feature API you can use > > for this). Notwithstanding that, you would have to add a client call > > to poll for events or (better) to expose the file descriptor so that > > callers can use it in select(2)/poll(2). > > Yeah, I expect the remote implementation will be the worst part! Thanks > for the pointers. One thing i would like to make sure for remote is that we can reuse the existing connection, as opening a second connection initiated by the server may give troubles with firewalls. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list