[libvirt] [RFC] Events API

[Daniel P. Berrange]

On Fri, Sep 19, 2008 at 11:14:07AM +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.
> 
> >   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).

Making a client poll for events is evil because it prevents the CPU
going into low power mode when nothing is happening. Exposing a FD
severely limits your flexibility, because libvirt then has no control
over when the FD is being monitored - you may well not want it being
select'd on all the time - and/or want to change the events being
monitored for at various times. 

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

Yes, the DBus approach (which is what I followed for the src/events.h
API) is the way I like best. It doesn't require libvirt to do tricks
internally with threads, and doesn't force a particular event loop
impl onto applications, and still allows libvirt full control over
just when & how FD is addded to the event loop for monitoring.

Daniel

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|