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

On Wed, 2008-11-05 at 11:51 +0000, Daniel P. Berrange wrote: Here's what I'm seeing when registering for dbus watch callbacks. In halNodeDriverStartup (in node_device_hal.c in the submitted host dev enum patch), I register for dbus watch callbacks: /* Register dbus watch callbacks */ if (!dbus_connection_set_watch_functions(dbus_conn, add_dbus_watch, remove_dbus_watch, toggle_dbus_watch, NULL, NULL)) { fprintf(stderr, "%s: dbus_connection_set_watch_functions failed\n", __FUNCTION__); goto failure; } And then I instrumented add/remove/toggle_dbus_watch. add_dbus_watch is called twice as soon as we register the watch functions: add_dbus_watch 0xae4200 fd 6 flags 0x2 enabled 0 add_dbus_watch 0xaeb950 fd 6 flags 0x1 enabled 1 *** DUPLICATE HANDLE 6 at [0] *** So here we have two different DBusWatches sharing the same unix fd. In this case, the first one (POLLOUT flags) is disabled, and never toggled, so things happen to work just fine. The current qemud AddHandleImpl will in fact overwrite the first entry with the second, so it has totally lost the first watch. But this is just lucky. Because the behavior of adding a duplicate handle is undefined, the implementation could just as well have ignored the second entry, in which case DBus events would never be received. I'll look into the glib handle-watching code (which I'm not familiar with currently) and see how it behaves, but I can't imagine it doesn't support this when DBus watches clearly require it. Dave