Hiding internal DBUS use inside a library

[Lennart Poettering]

On Thu, 25.08.05 16:44, Havoc Pennington (hp at redhat.com) wrote:

> With GNOME apps, set_timeout_functions() will always be called by the
> GLib main loop stuff, and set_max_received_size() would never be called
> (it's a specialized function used only by the message bus).

Wrong. Our client library for the avahi mdns/dns-sd responder tries to
abstract DBUS from the user. Hence it WILL call
set_{timeout,watch}_functions(), even when used by Gnome apps.

> > 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.
> 
> The point is to share the connection among code modules. i.e. inside
> GNOME, all GNOME libraries and portions of a GNOME app can use the same
> connection because it's assumed/defined that DBusConnection is used with
> the GLib main loop.

If it makes sense to share DBusConenctions in Gnome modules then Gnome
should implement the connection recycling, not the core DBUS system!

> We do the same thing with the X display connection maintained by GTK.
> (And KDE does the same with the one for Qt.)

I doubt that simply copying this behaviour from GTK to DBUS without
second thought makes sense.

> If you don't share the connection you'd have 20 open connections per app
> or more quite easily, which is noticeable overhead.

Is it really such a overhead? I doubt that. If you share the
DBusConnection with too many modules you'll end up iterating though
signal handlers ("module #1, is this signal for you? no? ok, module #2
is this signal for you? no? ..... module #4711 is this signal for you?
no? hmm, i guess i have to discard it then, what a pity for the lost
CPU cycles for nothing"). In contrast when using seperate fds for
different modules only the module that wants the signal will get it.

> > Did I miss something? Is there already a way to deal with this cleanly?
> 
> There is a way to do it with today's libdbus, because nothing about
> dbus_bus_get() is magic. You can just call
> dbus_connection_open_private() then dbus_bus_register(); the rest of the
> code in dbus_bus_get() is just maintaining the shared connection global
> variable.

Yes, we already implemented this for Avahi 0.1. However we
still have a compile time variable for the system bus address, which
must be set correctly to match DBUS' own. This is ugly and doesn't
belong in Avahi, but in DBUS. 

(the least that could be done is exporting the bus address in the
pkg-config file as variable)

Lennart

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