Re: [libvirt] [RFC] Events API

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. > 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. 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).

Actually there are a number of ways to do this -- IIRC dbus does something semi-elegant.