Re: [libvirt] [RFC] Events API
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