Tracking DBusWatches
Havoc Pennington
hp at redhat.com
Mon Feb 5 13:32:54 PST 2007
tsuraan wrote:
>
> Since the watches are supposed to be used for select(), I assume that it
> doesn't make sense to keep track of repeated watch additions that have
> the same file descriptor.
The two watches probably have different flags (one is supposed to be
watched for reading, one for writing). So they are in fact different and
you need to add both of them, with different conditions watched for
depending on the flags.
Looking at the main loop used by dbus-daemon itself, it appears to rely
on it being OK to pass the same fd to poll() twice with different flags.
I don't know if this is really OK; it's possible there's a bug here in
dbus-daemon.
One of the watches is for writing and will only be enabled when there
are outgoing messages to write. The other message is for reading and
will more or less always be enabled.
There are no ABI guarantees about which watches will be added and when
they will be toggled, though.
> Should I just free redundant watches, or is
> dbus doing that behind my back? Or, if I were to write a somewhat less
> trivial program, would the out-of-date watch be eventually given to the
> remove and free functions that were registered with
> dbus_connection_set_watch_functions?
libdbus does all memory management of DBusWatch for you, all you have to
do is be sure you drop any references to the watch when the remove
function is called. All watches should be removed when a connection is
destroyed.
The free function passed to set_watch_functions() is to free the "void
*data" you supplied when the DBusConnection is destroyed. You need not
supply a free function if you did not supply any data that needs freeing.
Havoc
More information about the dbus
mailing list