Python <--> d-bus <--> c++ woes

[Kip Warner]

Hey list,

I'm still having some difficulties getting my Python and C++
application to intercommunicate. Without boring folks on what the
applications do, in a nutshell, the Python application is a Gtk+3
front end for a lower level scientific command line tool written in C++.

The Python application is user invoked. It connects to the session bus
before in turn invoking the C++ application. The C++ application then
registers itself on the session bus as well. When it has succeeded and
the Python application finds it on the bus, the Python application
emits a "Ready" signal to alert the C++ application to go ahead and
start doing some work. All of this happens via simple signals with no
need for advanced methods.

The problem is the "Ready" signal the Python application emits
sometimes isn't received by the C++ application - and sometimes even
when it is, I notice there is a delay of upwards of 20 seconds or more
on occasion.

I will try to illustrate the above step by step. First the Python
application starts up and connects on the session bus (line 37):

        <https://bazaar.launchpad.net/~avaneya/avaneya/trunk/view/head:/Extras/Viking%20Lander%20Remastered/Launcher/Source/RecoveryPage.py#L37>
        
Next the C++ application is invoked. It registers itself on the session
bus (line 160):
        
        <https://bazaar.launchpad.net/~avaneya/avaneya/trunk/view/head:/Extras/Viking%20Lander%20Remastered/Extractor/Source/DBusInterface.cpp#L160>
        
Next the Python application attempts to connect to the C++ application's
d-bus service. The Python application keeps trying (loop at line 82)
until it succeeds. It then emits the "Ready" signal (line 122):
        
        <https://bazaar.launchpad.net/~avaneya/avaneya/trunk/view/head:/Extras/Viking%20Lander%20Remastered/Launcher/Source/RecoveryPage.py#L68>
        
Meanwhile the C++ application has done some initialization. It is
available to start doing work by the time it has registered on the
session bus, but does not actually start yet. It awaits by blocking
until this "Ready" signal sent by the Python application is received
(line 242) before it does the actual work it needs to do:
        
        <https://bazaar.launchpad.net/~avaneya/avaneya/trunk/view/head:/Extras/Viking%20Lander%20Remastered/Extractor/Source/DBusInterface.cpp#L242>

As mentioned earlier, the problem is the "Ready" signal sometimes isn't
received in the C++ application's blocking method that waits for it, and
sometimes even when it is received, I notice there is a delay of upwards
of 20 seconds or more. Note that at the time the Python application
fired off the "Ready" signal, the message queue was manually flushed so
I don't think that could have been an issue (line 130 of
RecoveryPage.py).
        
I've gone through what I could understand of the XDG d-bus specification
and my selected implementation's documentation. Still though, I haven't
been able to solve this problem for a few weeks now and suspect there is
a trivial fix that doesn't require major code re-factoring. Any friendly
help would be greatly appreciated. 

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130228/a9cdf54c/attachment.pgp>