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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list