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