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?? 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). Dave On Mon, 2008-09-22 at 16:22 +0100, Daniel P. Berrange wrote: > No, this the wrong approach. This is defining an event loop impl - we > don't want todo that. We need to define an API to let an application > provide a set of callback for libvirt to talk to an existing event > loop impl. ie a way for libvirt to register FD watches and timeouts, > not a way for apps to manually process libvirt events in this way this > example shows. > > The public API for this is along the lines of that currently defined > in the src/events.h file. > > There are a set of functions libvirt needs in order to register actions > for FDs, and/or timeouts. So the public API should consist of a way > to register impls of these APIs > > typedef int (*virEventAddHandleFunc)(int, int, virEventHandleCallback, void *); > typedef void (*virEventUpdateHandleFunc)(int, int); > typedef int (*virEventRemoveHandleFunc)(int); > > typedef int (*virEventAddTimeoutFunc)(int, virEventTimeoutCallback, void *); > typedef void (*virEventUpdateTimeoutFunc)(int, int); > typedef int (*virEventRemoveTimeoutFunc)(int); > > void virEventRegisterImpl(virEventAddHandleFunc addHandle, > virEventUpdateHandleFunc updateHandle, > virEventRemoveHandleFunc removeHandle, > virEventAddTimeoutFunc addTimeout, > virEventUpdateTimeoutFunc updateTimeout, > virEventRemoveTimeoutFunc removeTimeout); > > A separate libvirt-glib.so, would provide a API call > > virEventRegisterGLib() > > which calls virEventRegisterImpl() with a suitable implementation for > glib. An application like virt-manager which uses glib and wants events > would then calll virEventRegisterGLib(). If it had a custom event loop > of its own, then it could call virEventRegisterImpl() directly with its > special impl. > > It may be worth making our public API even more closely aligned with > dbus - see dbus-connection.h and dbus-server.h - so people writing > glue functions for it could just reuse what they've already written > for dbus. > > typedef dbus_bool_t (* DBusAddWatchFunction) (DBusWatch *watch, > void *data); > typedef void (* DBusWatchToggledFunction) (DBusWatch *watch, > void *data); > typedef void (* DBusRemoveWatchFunction) (DBusWatch *watch, > void *data); > > typedef dbus_bool_t (* DBusAddTimeoutFunction) (DBusTimeout *timeout, > void *data); > typedef void (* DBusTimeoutToggledFunction) (DBusTimeout *timeout, > void *data); > typedef void (* DBusRemoveTimeoutFunction) (DBusTimeout *timeout, > void *data); > > dbus_bool_t dbus_server_set_watch_functions (DBusServer *server, > DBusAddWatchFunction add_function, > DBusRemoveWatchFunction remove_function, > DBusWatchToggledFunction toggled_function, > void *data, > DBusFreeFunction free_data_function); > dbus_bool_t dbus_server_set_timeout_functions (DBusServer *server, > DBusAddTimeoutFunction add_function, > DBusRemoveTimeoutFunction remove_function, > DBusTimeoutToggledFunction toggled_function, > void *data, > DBusFreeFunction free_data_function); > > A 'watch' in DBus terminology is a file descriptor monitor. > > Daniel -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list