Hiding internal DBUS use inside a library

[Havoc Pennington]

On Thu, 2005-08-25 at 23:07 +0200, Lennart Poettering wrote:
> 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.
> 

Then you should use a private connection. I would suggest that the
shared dbus connection is defined to be in use by the primary main loop
or event system of the application. For GNOME applications, this would
be the GTK main loop, for apps not using a toolkit this would be the
app's own custom event loop.

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

The reason I don't agree is that a non-GNOME library may have legitimate
reasons to use "the dbus connection attached to the primary event loop
of the application" rather than a private connection. There's no reason
to require linking to GNOME libs in order to access the "primary bus
connection."

We could explicitly allow the primary main loop to "grab ownership" with
an API like:

 dbus_bus_register_main_loop (void *cookie);
 
where the code that calls set_watch_functions() would call the above
function. At that point, any future call to set_watch_functions() will
fail and print a warning.

But I think it's sort of overkill.

> > 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.

I don't. There's a fixed limit on number of file descriptors available,
and DBusConnection is not a very small object.

>  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.

We could optimize that away pretty well with a hash table, and the
overhead I'm concerned about is primarily space not speed.

> 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)

That is in bugzilla already... feel free to provide a patch...

Havoc