Re: [Libvir] Re: Asynchronous notifications of domain start/stop
Daniel Veillard wrote:
For the callback model to work you need the application to call the
library
in some way (to then check the condition and do the callback), to me threading
in the library is not a good working model because then you callback from a
different thread and lot of confusion/races ensue.
Yep, in that point threads equally evil like callbacks from signal
handlers. Well, slightly better as you can at least use pthread locking
primitives then. But forcing apps into using threads isn't very nice. I
avoid threads when possible exactly to get around the locking hassle.
I resisted so far adding events in libvirt API precisely to keep
the
level of complexity of the API down. If we go there, then an fd based
mechanism with a function called by the user to get the information has
my preference.
/me too ;)
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.
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).
cheers,
Gerd