Private connections

[Thiago Macieira]

Havoc Pennington wrote:
>Sharing the same connection between all code in the same process is
>intended to be the normal case; most usage of private connections that
>I've heard about was due to working around bugs in libdbus. I would
>certainly consider it a bug in libdbus if typical apps needed multiple
>connections, because it just isn't a good idea if every app has a bunch
>of separate bus connections open. (It's significantly wasteful, and much
>less importantly, encourages race conditions since there's no ordering
>between messages on different connections.)

I didn't understand: do you also consider it a bug if the bindings require 
a private connection?

AFAIK, all of the major bindings do that, for various reasons. In the 
QtDBus binding, there are two main reasons, none of which I consider to 
be bugs in libdbus:

1) we take the entire object tree to ourselves. So it makes no sense for 
anyone else to anyone else to try and register objects on it. We do that 
because we keep our own tree and handle method calls via the message 
filter, instead of using dbus_connection_register_object_path. 
Technically, we could use dbus_connection_register_fallback for our 
objects that export their own tree, but this would complicate things 
unnecessarily (IMHO) and is not planned for QtDBus 4.3.

2) the callback for adding/removing/toggling timeouts and watches are not 
thread-safe, not reentrant and can only be called from the main GUI 
thread.

#2 is a requirement of the way everything related to QObject works: you 
mustn't touch it except in the thread that it lives on. This includes 
timers and fd watchers. In turn, this means we cannot allow any use of 
the DBusConnection from outside that thread, because it could at any time 
request changes.

I think I have devised a solution for #2, but it depends greatly on 
cooperation between the threads. It involves posting an event to the GUI 
thread and having that one instead do the adding/removing/toggling. The 
consequence is that the action is not immediate. Therefore, some libdbus 
constructs may simply not be allowed because of deadlock issues. If I 
control all of the possible libdbus entry points in my connection, I can 
fix that.

There are other issues that involve shared connections. We discussed them 
in IRC another day and I think it would be a good idea to bring them 
here. When using a shared connection, how/when does one set up the 
DBusWatch and DBusTimeout callbacks?

I.e., do we depend on a binding to do that? Or should the application 
itself add those callbacks? What if it's a library?

Whoever does so, if it's not the application, what should it do when it no 
longer needs D-Bus? Is it mandated that it keep the callbacks until the 
program exits? What happens if it was a plugin that is about to be 
unloaded from memory?

I see no solution short of dropping those functions and knowing the main 
loop ourselves.

>It should be safe for any *app* (but no libraries) to use paths without
>a domain name prefix, just as you can write Java classes in the default
>package.

That's another reason why we're using a private connection: all of the KDE 
libraries did away with the /org/kde path prefix. We'd have a hard time 
convincing them to change that.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070222/efe4ed25/attachment.pgp