Qt Signals do not connect properly to rpyc remote modules

[latchr]

What is affected by this bug?

Any remote modules (using rpyc as normal for Qudi) that need to "hear" signals from a module running on a separate computer.

Up until now remote modules have been hardware modules, and it is not common for hardware modules to need to hear signals from other modules. However, at Macquarie Uni we are needing to develop remote GUI modules and they are heavily dependent on signals for communication from the logic.

When does this occur?

When the signal is emitted on the remote module (running on a separate computer), the local Signal.connect(method) is not run.

Where on the platform does it happen?

I first encountered this issue with a poorly-designed spectrometer development branch, trying to fix the bug where Qudi hangs while the winspec spectrometer acquisition takes place. That attempted fix made use of signals to run the acquisition in a separate thread, but things were a bit mixed up and some signals were fired from the logic and "heard" by the hardware. With the hardware module on a remote virtual machine things did not work.

Now we need to have remote gui modules, and the problem is everywhere because we rely on signals for the logic modules to communicate back to the GUI.

How do we replicate the issue?

The fastest way to replicate this issue is to put remoteaccess: True in the config for counterlogic on computer A. Then in computer B have counterlogic use remote: XX.XX.XX.XX:1234/counterlogic as counterlogic. Open the counter gui on both computers. The counter gui on computer B can start counting and adjust counter parameters as expected, and because there is only the logic on computer A everything is live-updated on the GUI at computer A. However, computer B GUI does not show the count data and does not respond properly when the counterlogic.startCount() is called from the console.

Expected behavior (i.e. solution)

GUI modules should function properly as remote modules. The config is easy to write and it almost works already, so this is not a big stretch for typical users to imagine.

Other Comments

The problem seems to be that QtCore signals do not interact with the "event loop" on computer B. Or perhaps there is something about rpyc that does not pass signals properly.

@drogenlied, @kay-jahnke, @a-stark, @Neverhorst, @mvbnano do you guys have any helpful ideas here?

[mvbnano]

@latchr here is a link to the potentially useful repo we found just prior to leaving this afternoon:

qt-remote-signals

Note that this is written in C++.

[mvbnano]

I am just about to head out so havn't read this much, but maybe QtDBus, which is a part of PyQt

The QtDBus module provides an interface that extends the Qt Signals and Slots mechanism, allowing one to connect to a signal emitted remotely as well as to connect a local signal to remote slot. source

Following this, here is a link to where DBus is discussed on the Qt website: PySide DBus Integration

[drogenlied]

Known issue ever since there is remote module functionality.

Qt objects are not first-class citizens in Python and require workarounds. numpy objects have similar problems.