Hiding internal DBUS use inside a library

[Lennart Poettering]

On Thu, 25.08.05 20:19, Havoc Pennington (hp at redhat.com) wrote:

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

But how does one make sure that the DBusConnection that is returned by
dbus_bus_get() has already been initialized to work with the main
event loop?

An example: my library internally uses the system bus. so it calls
dbus_bus_get() for the system bus. How does it know that
dbus_connection_setup_with_g_main() (or what ever is the right thing
to do for registering the connection with the main loop) has already
been called for that 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.

Hmm, the least what could be done is to let set_watch_functions() fail
if the watch functions have already been set previously. Right now
each call succeeds and straneg things happen.

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

Ok. That's a good point. I didn't consider memory consumption. 

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

The current API doesn't allow that this is optimized using a hash
table.

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

Ok, will do.

Lennart

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