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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list