RE: [libvirt] [RFC] making (newly public) EventImpl interface moreconsistent

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(a)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: 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(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list