DBusConnection* from a QDbusConnection

maxprofitisback maxprofitisback at gmail.com
Thu Sep 30 05:26:16 PDT 2010

Thiago Macieira wrote:
> On Thursday 30. September 2010 09.34.40 maxprofitisback wrote:
>> Thiago Macieira wrote:
>>> On Wednesday 29. September 2010 15.59.49 maxprofitisback wrote:
>>>> Hi,
>>>> Is it possible to get a DBusConnection from a QDbusConnection?
>>> No.
>> In case of a Qt application which has a pool of
>> QDbusConnection::sessionBus() connections for communicating with
> It's not a pool. It's just one connection (one QDBusConnection, wrapping one
> DBusConnection).

Ok, sorry I am not familiar with D-Bus vocabulary. I mean by "pool" of
QDbusConnection::sessionBus something like that:
within QThreadStorage array.

>> external components and has to use too an existing "client API" written
>> with DBus-GLib bindings for communicating with other components.
>> This "client API" use a separate sessionBus from the pool of connection
>> of the Qt application.
> Correct.
>> How can I avoid DBus threading issues between the pool of connection and
>>   the DBus-Glib client API ?
> What threading issues are you talking about? Note that dbus-glib is not
> considered thread-safe.
I get random crash in my dbus-glib client API when it tries to call a
blocking method to my external component: dbus_watch_handle (0x0, 2).

> If you mean the reentrancy issue of calling back to yourself, there are two
> ways: 1) don't do it. You must know that the call will route back to the
> current program and you must instead not do the call via D-Bus
> or 2) make it a non-blocking (asynchronous) call.
Don't understand :(

>> I was thinking of reusing somehow a sessionBus created from the pool of
>> connections within the DBus-Glib client API ...
> You can't do that. QtDBus must reserve the connection to itself due to the
> many assumptions about the state of the connection, the objects exposed and
> where messages go. Some of these assumptions are in place due threading issues
> and reentrancy issues.
> If your application is constrained for resources (e.g., low-powered device
> where opening many D-Bus connections is a non-negligible penalty), the only
> advice I can give you is to skip one binding or the other, and use a single
> one for all your D-Bus needs.
So, in my case, I should rewrite my dbus-glib client API with QtDBus
bindings. But if the external component ("server") supposed to interact
with this API is again exposing D-Bus interfaces with dbus-glib
bindings, will I get some errors?


More information about the dbus mailing list