Re: [libvirt] [RFC] making (newly public) EventImpl interface more consistent
I have no strong feeling w.r.t. the reregistration of an fd, I would rather error and not state it's undefined though. For the java bindings, yes please :-) that way I would be able to push a new release too end of next week. I'd like to get the Xen driver domain events in that release as well. I'm working through some bugs with these, but I think it should be ready for review sometime this week, or beginning of next. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] making (newly public) EventImpl interface more consistent
On Mon, Nov 03, 2008 at 10:51:36AM -0500, David Lively wrote: Hi Folks - Since virEvent???RegisterImpl is now public (in libvirt.h), a nagging concern of mine has become more urgent. Essentially this callback gives clients a way of registering their own handle (fd) watcher and timer functionality for use by libvirt. What bugs me is the inconsistency between the handle-watcher and timer interfaces: the timer add function returns a timer id, which is then used to identify the timer to the update and remove functions. But the handle-watcher add / update / remove functions identify the watcher by the handle (fd). The semantics of registering the same handle twice aren't specified (what happens when we pass that same fd in a subsequent update or remove?). Even worse, this doesn't allow one to manage multiple watches on the same handle reasonably. IMHO it doesn't make sense to register 1 file descriptor multiple times - once the I/O has been processed by one handler, there's nothing more another handler can do. I think there are a few options if the FD is already registered when calling 'add' - Return an error code - Ignore the new request - Remove the existing callback - Say behaviour is undefined Trying to define any more complex semantics than this will limit our ability to integrate with existing event loop implementations. We currently defacto do option 3, which is fine provided no libvirt code ever registered the same FD more than once - which we don't. I think I'm inclined to stick with saying behaviour is undefined, and if a libvirt driver needs to somehow process the FD events in multiple places it can deal with that at a higher level - eg it can register one callback to get the notifications perform the I/O, and then fire off some notifications to the bits of the driver than ned to know when the I/O is complete. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] making (newly public) EventImpl interface more consistent
On Tue, Nov 04, 2008 at 08:18:33AM -0500, Ben Guthro wrote: I have no strong feeling w.r.t. the reregistration of an fd, I would rather error and not state it's undefined though. For the java bindings, yes please :-) that way I would be able to push a new release too end of next week. I'd like to get the Xen driver domain events in that release as well. I'm working through some bugs with these, but I think it should be ready for review sometime this week, or beginning of next. Okay, cool, as usuall the sooner the better. Note that I will be away from the machine beginning of next week (french day off + moving) so if you could come up with a first version by friday that would allow an early feedback from me. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] making (newly public) EventImpl interface more consistent
Hi Folks - Since virEventRegisterImpl is now public (in libvirt.h), a nagging concern of mine has become more urgent. Essentially this callback gives clients a way of registering their own handle (fd) watcher and timer functionality for use by libvirt. What bugs me is the inconsistency between the handle-watcher and timer interfaces: the timer add function returns a timer id, which is then used to identify the timer to the update and remove functions. But the handle-watcher add / update / remove functions identify the watcher by the handle (fd). The semantics of registering the same handle twice aren't specified (what happens when we pass that same fd in a subsequent update or remove?). Even worse, this doesn't allow one to manage multiple watches on the same handle reasonably. So why not make the handle add function return a watch id (analogous to the timer id returned by the timer add fn)? And then use this watch id to specify the handle-watcher in the update and remove functions. This conveniently handles multiple watches on the same handle, and also makes the handle-watching interface more consistent with the timer interface (which is registered at the same time). We'd pass both the watch id and the handle (fd) into the watch-handler callback. I'd like to implement and submit this (along with fixups to the event test code) if there are no objections. Thanks, Dave P.S. I'm currently working on Java bindings to the new event code ... -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
