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 :-)
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()). 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).
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. Thanks, Dave