DBusConnection* from a QDbusConnection

[maxprofitisback]

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:
http://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/dbus/connectionmanager.cpp
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?

Thanks