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 :|