I'll respond now while I'm looking at this, as Dave may not be able to get to this until later today

I was talking with Dave about this yesterday, and if I'm not mistaken, this idea comes from some of the implementations for either DevKit, DBus, or libHAL (I can't remember which one he was looking at at that particular moment)

Essentially, if I understand the model correctly, they have 2 fd sets - one for reading, one for writing.

I could see an additional use where you have multiple callbacks - one for data, and one for error handling. These 2 calls to AddHandle would take the sale fd, but would have different event mask sets, for the different callbacks.

It does make the model with the timeouts more symmetric.

-----Original Message-----
From: libvir-list-bounces@redhat.com on behalf of Daniel P. Berrange
Sent: Tue 11/4/2008 5:10 AM
To: Dave Lively
Cc: libvir-list
Subject: Re: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent

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