[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]