Hiding internal DBUS use inside a library

Lennart Poettering mzqohf at 0pointer.de
Tue Aug 23 12:48:36 PDT 2005


Hi!

I am working on a library that makes internal use of DBUS. It connects
to the system bus and does some work there. I want to hide the fact
that the library uses DBUS completely. Unfortunately this is not
possible wth the current API, as it seems. Due to connection recyling
we might get access to a connection some other part of the application
(maybe some other library?) registered and might have installed
watch/timeout handlers for. If we now overwrite those handlers with
our own DBUS goes nuts.

In short: a library that uses the current API function dbus_bus_get()
is simply broken.

Honestly I think that the whole connection recycling thing is a really
bad idea. The fact that one part of a process might call functions
like dbus_connection_set_timeout_functions() or
dbus_connection_set_max_received_size() on a DBusConnection and
overwrite values other parts already set earlier without even knowing about it
is a royal error source. 

And when does this connection recycling ever become handy? What is the
gain of the added complexity? Either a connection is created by a
library, in which case recycling is a bad idea due to the reasons
described above. Or it is created by the main program, in which case
one can asssume that the programmer knows what to do and shares
the DBusConnection on his own behalf if he wants to.

Would a patch that removes the connection recyling entirely be
accepted?

In case not: would a patch adding a new function
dbus_bus_get_private() which is identical to dbus_bus_get() but uses
dbus_connection_new_private() internally, be accepted?

Did I miss something? Is there already a way to deal with this cleanly?

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/


More information about the dbus mailing list