[libvirt] [RFC] Events API
David Lively
dlively at virtualiron.com
Fri Sep 19 15:08:37 UTC 2008
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 :-)
>
> > 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()). 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).
>
> 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.
Thanks,
Dave
More information about the libvir-list
mailing list