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 :|