On Wed, Jul 18, 2007 at 01:23:22PM +0200, Gerd Hoffmann wrote:
> That way except for the fd everything is synchronous and
> purely within the application flow of control. The problem is how to
> then feed the fd when "something occurs" especially since the something
is
> happening in a different process or even a different domain.
What troubling events do you have in mind? For remote you'll have the
socket to select() on. As I far I know the very same protocol is used
for qemu, so you probably have a socket too, right? For xen you can
just use the xenstore fd. Dunno on the network stuff. Who manages the
network? Probably the libvirtd daemon too? Then the notifications can
go through the libvirt <-> libvirtd socket connection, so you have a fd too.
If you give directly the fd of the socket used to talk internally to the
daemon then you must allow for case where there is data to read but no
even will be generated in the function, because since you don't have the
library filtering you can't be sure what's available is something the
application is interested in.
For example if doing a migration a lot of traffic may happen on multiple
sockets before the user see an event he's actually interested into.
There is so much nastyness once you break the purely synchronous model.
What might be needed is allowing multiple file handles (one socket
to
xenstore, one socket to libvirtd) so libvirt can collect events from
different sources. It becomes a bit difficuilt at that point. avahi
has that problem too. They have a "give me functions to register and
unregister filehandles"-style api for that. And some helper functions
to make that easy for apps using the event loops of the usual gui libs
(glib/gtk, qt).
Could be a possibility, the other one is to create one thread internal
to the library but limited purely to doing I/O, still I find this disgusting.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/