Re: [libvirt] [RFC] Events API
On Mon, Sep 22, 2008 at 03:15:25PM -0400, David Lively wrote:
Okay, at long last, I see what you mean (I think). Apps using
libvirt
events must register an EventImpl via virRegisterEventImpl. Internally,
suppose we implement events via an anonymous pipe. libvirt would call
EventImpl.addHandle(pipe_read_fd, POLLIN ..., __virHandleEvents, conn)
so the app's main loop would monitor fd (in whatever manner it chooses),
then call __virHandleEvents(fd, conn) when it detected activity.
__virHandleEvents would pull the event from the pipe and dispatch
handlers as appropriate. We'd call eventImpl.removeHandle(pipe_read_fd)
when the domain goes away. Am I finally on the right track??
Well the answer will depend on the particular virtualization driver. For
the remote driver (which includes QEMU + LXC + any others running inside
the daemon) you already have a file descriptor that can be monitored - the
UNIX/TCP socket to the daemon.
For the Xen driver we would grab the xenstored UNIX socket file descriptor
and register xenstore watches - the FD would become readable when the
watch fires.
So, yes, the remote driver would register its FD with EventImpl.addHandle.
In the GLib<->libvirt event loop binding, this would in turn register the
FD with the GLib event loop and a callback wrapper. The GLib<->libvirt
event loop binding would detect the neccessary poll condition, invok the
the callback associated with that FD, which would then invoke the callback
actually regisstered by the remote driver
virHandleEvents() is not something that would directly play a part - that's
a specific part of the libvirtd daemon's event loop impl.
If so, are you proposing that we simply make the existing
src/events.h
interface public? At this point, I don't see the need for anything but
addHandle and removeHandle (but I can see how the others might be useful
to libvirt eventually).
The 'updateHandle' method was essentially an efficiency method - it
allows us to change the poll events that a FD is being monitored for
without having to register & unregister. This both helps efficiency
of the event loop impl, and means the impl can guarentee this operation
will never encounter OOM.
If we split the virEventRegisterImpl() function into two, in the same
way that dbus does - virEventRegisterWatchImpl, virEventRegisterTimeoutImpl
then we could just make the watch impl public for now and worry about the
timeout impl later if there turns out to be a need for it.
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 :|