[libvirt] [RFC] Events API

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/