[libvirt] [RFC] making (newly public) EventImpl interface more consistent

Daniel P. Berrange berrange at redhat.com
Tue Nov 4 10:10:49 UTC 2008

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.

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

More information about the libvir-list mailing list