Strange interaction between RPyC and pyqtgraph #517
Comments
|
I'm working with @sidneycadot on an RPyc application and did some further debugging on this issue. I found that the issue is triggered because pyqtgraph calls During application cleanup, pyqtgraph runs a piece of cleanup code (link), which slightly simplified looks like: for o in gc.get_objects():
if isinstance(o, ...):
...This cleanup code hits all live Python objects, including any RPyc netrefs. When The following simplified client program reproduces the issue without involving pyqtgraph: import sys
import logging
import time
import rpyc
# Configure the logging infrastructure.
logging.basicConfig(level=logging.DEBUG)
# Connect to the server's MyService instance.
connection = rpyc.connect("localhost", 30000)
print("Connected.")
time.sleep(1)
print("Now triggering the issue ...")
# Trigger the issue by running "isinstance()" on the remote object.
print(isinstance(connection.root, int))
print("Triggered the issue.")
time.sleep(2)
connection.close()To summarize:
I'm not sufficiently experienced with RPyc to know what the correct solution is here. One may take the opinion that pyqtgraph should not be calling One may also take the opinion that RPyc objects not supporting The warning can be avoided by explicitly exposing the class MyService(rpyc.Service):
def __init__(self):
super().__init__()
self.exposed_value = 42
self.exposed___class__ = self.__class__Again, I don't know enough about RPyc to understand whether this is the intended way to enable access to the |
|
It's a bit of a difficult question how one would /want/ isinstance() to behave. At the client side, do we want to do the check on the proxy itself, or on the remote object? Both could be useful I think, depending on circumstances. A technical alternative could be to override the __instancecheck__ class method. |
|
Okay @jorisvr figured out the root cause, which is that 'isinstance' on netrefs doesn't work as expected under some circumstances. In my particular (PyQt) application it's a bit hard to work around that, because both PyQtGraph and my application use an "aboutToQuit" handler, the calling-order at program end of which is undefined. We (@jorisvr) and myself found two workarounds for the original problem: On the pyrpc side, setting the protocol config attribute "allow_all_attrs" to True makes the On the PyQtGraph side, the garbage collection sweep that triggers the
|
Using Python 3.11 and RPyC 5.3.0, I see a very puzzling interaction when talking to an RPyc server from a client that uses a pyqtgraph PlotWindow widget. (Pyqtgraph is a well-known framework for making plots in python programs that implement a Qt-based GUI).
I am testing under Linux, with PyQt5 but the issue is also present when using PySide6.
The server code is as plain and simple as can be:
The client side is somewhat more involved. I open a connection to the server and interact with it. Next, I run a simple GUI application that stops when the user closes the window. Finally, I close the connection:
The issue is that as soon as I close the GUI application, the server-side emits a debugging message that strongly suggests something has gone wrong. This is before the connection is closed:
There's a couple of ways I can make this debugging noise disappear.
(1) If I don't interact from the client with the server other than opening/closing it, the issue disappears.
(2) If I use a plain QWidget rather than a pyqtgraph PlotWidget, the issue disappears.
My conclusion is that there is some kind of a funky interaction between pyqtgraph and rpyc; but I am not well-enough versed in both their codebases to investigate any further -- so I am hoping someone here can reproduce the issue, and see what's going on.
The text was updated successfully, but these errors were encountered: