PyQt5 - get signal from subprocess in main
-
Hi all..
i am going crazy on this.. i have a subprocess that emits a signal. i want to connect a function running in the main process/thread to this signal, but it does not seem to be working.
here is a simple code to demonstrate my problem:
import sys import server import serverSubprocess from PyQt5 import QtWidgets from PyQt5.QtWidgets import * class UiMainWindow(QMainWindow): serverSp = serverSubprocess.TcpSubprocess() def __init__(self): super(UiMainWindow, self).__init__() self.serverObj = server.Server() self.serverObj.subproc_signal.connect(self.got_signal) self.label = QLabel("value") self.setCentralWidget(self.label) self.serverSp.start_server() self.show() def got_signal(self, myvalue): self.label.setText(str(myvalue)) if __name__ == '__main__': app = QtWidgets.QApplication(sys.argv) MainWindow = QtWidgets.QMainWindow() ui = UiMainWindow() sys.exit(app.exec_())
import subprocess from PyQt5.QtCore import * class TcpSubprocess(QObject): # Start the server as a subprocess p = subprocess.Popen def start_server(self): command = ['python', 'server.py'] self.p = subprocess.Popen(command)
import sys from PyQt5.QtCore import * class Server(QObject): subproc_signal = pyqtSignal(int) def __init__(self): QObject.__init__(self) self.send_signal() def send_signal(self): print("emitting signal") self.subproc_signal.emit(123) if __name__ == '__main__': app = QCoreApplication(sys.argv) server = Server() sys.exit(app.exec_())
what am I doing wrong? any help is geratly appreciated...
-
Hi all..
i am going crazy on this.. i have a subprocess that emits a signal. i want to connect a function running in the main process/thread to this signal, but it does not seem to be working.
here is a simple code to demonstrate my problem:
import sys import server import serverSubprocess from PyQt5 import QtWidgets from PyQt5.QtWidgets import * class UiMainWindow(QMainWindow): serverSp = serverSubprocess.TcpSubprocess() def __init__(self): super(UiMainWindow, self).__init__() self.serverObj = server.Server() self.serverObj.subproc_signal.connect(self.got_signal) self.label = QLabel("value") self.setCentralWidget(self.label) self.serverSp.start_server() self.show() def got_signal(self, myvalue): self.label.setText(str(myvalue)) if __name__ == '__main__': app = QtWidgets.QApplication(sys.argv) MainWindow = QtWidgets.QMainWindow() ui = UiMainWindow() sys.exit(app.exec_())
import subprocess from PyQt5.QtCore import * class TcpSubprocess(QObject): # Start the server as a subprocess p = subprocess.Popen def start_server(self): command = ['python', 'server.py'] self.p = subprocess.Popen(command)
import sys from PyQt5.QtCore import * class Server(QObject): subproc_signal = pyqtSignal(int) def __init__(self): QObject.__init__(self) self.send_signal() def send_signal(self): print("emitting signal") self.subproc_signal.emit(123) if __name__ == '__main__': app = QCoreApplication(sys.argv) server = Server() sys.exit(app.exec_())
what am I doing wrong? any help is geratly appreciated...
-
@Igor86
You cannot use signals/slots across process boundaries, where did you get such an idea from? "Processes" and "threads" are not the same thing.@JonB the thing i coded few days ago, where i placed a tcp server on its own thread, did not work as expected. i found that it is not allowed to run the TCP server on a different thread. so i thought of giving it its own process, and that worked. Qhat stopped working tough was the signals. after some googeling i found a few posts that said what should be changed, and also chatgpt said it is possible. but all i tried did not work. and your answer explains why...
so the obvious next question would be is there a solution to this? if something runs on its own process, is tehre a way to comunicate between the processes like signals do, and send over data like numpy arrays?
Thank you for your precious help.
-
@JonB the thing i coded few days ago, where i placed a tcp server on its own thread, did not work as expected. i found that it is not allowed to run the TCP server on a different thread. so i thought of giving it its own process, and that worked. Qhat stopped working tough was the signals. after some googeling i found a few posts that said what should be changed, and also chatgpt said it is possible. but all i tried did not work. and your answer explains why...
so the obvious next question would be is there a solution to this? if something runs on its own process, is tehre a way to comunicate between the processes like signals do, and send over data like numpy arrays?
Thank you for your precious help.
@Igor86 said in PyQt5 - get signal from subprocess in main:
where i placed a tcp server on its own thread, did not work as expected. i found that it is not allowed to run the TCP server on a different thread.
I don't know what did not work as expected. You can run a TCP server on a thread of its own if that's what you want.
You can write a TCP client for that within the same process as the server if you really want (e.g. to test), but it's not very useful. Presumably in the real world you will have separate processes for the server and client, else there's not much point using TCP anything.
If you have separate processes connected over TCP they can communicate with each other by sending data over TCP. That's why you're using TCP in first place --- to have separate processes communicate, else you don't need TCP. They cannot communicate via Qt signals (unless you use Qt Remote Objects, but that's a different matter).
When one side receives data from the other side on the socket the receiver's
readyRead()
signal will fire. You can then read the data and act on it. That is the only place signals are fired, and it's within the receiver process, not between processes.P.S.
also chatgpt said it is possible
Well, if ChatGPT says that it must be correct! Like when it assured me that Bobby Charlton from England 1966 World Cup is dead. Difficult convincing it on that one... ChatGPT is about as good as the question you put in, what you make of the answer it returns, and what you think about how much has been left out :)
-
@Igor86 said in PyQt5 - get signal from subprocess in main:
where i placed a tcp server on its own thread, did not work as expected. i found that it is not allowed to run the TCP server on a different thread.
I don't know what did not work as expected. You can run a TCP server on a thread of its own if that's what you want.
You can write a TCP client for that within the same process as the server if you really want (e.g. to test), but it's not very useful. Presumably in the real world you will have separate processes for the server and client, else there's not much point using TCP anything.
If you have separate processes connected over TCP they can communicate with each other by sending data over TCP. That's why you're using TCP in first place --- to have separate processes communicate, else you don't need TCP. They cannot communicate via Qt signals (unless you use Qt Remote Objects, but that's a different matter).
When one side receives data from the other side on the socket the receiver's
readyRead()
signal will fire. You can then read the data and act on it. That is the only place signals are fired, and it's within the receiver process, not between processes.P.S.
also chatgpt said it is possible
Well, if ChatGPT says that it must be correct! Like when it assured me that Bobby Charlton from England 1966 World Cup is dead. Difficult convincing it on that one... ChatGPT is about as good as the question you put in, what you make of the answer it returns, and what you think about how much has been left out :)
@JonB You are right, i have not been very clear on the actual problem.
The main thread is from time to time delaying the tcp send because it is busy doing other things. not much, just a 50 ms... but for me in this application even 5 ms delay is a lot. so my idea was to put the tcp server on a different core so it is not affected by the other things going on on the main thread. this obviously didnt work as i expected. I found a extensive post on stackoverflow with also links to the official documentation that states that the tcp server should stay on the main thread as it could give unexpected results. my ultimate goal is to have a TCP server running that is not affected by anything that happens on the GUI o other modules of the main thread.. if it has its own core even better. But python is giving me a hard time on this...
as for chat GPT, yes i agree with you and my opinion is the same. but after having found results online that state that it is possible, i tried to give it a shot. unfortunately it did not work in this case and gave wrong information.
thanks for your help
-
@JonB You are right, i have not been very clear on the actual problem.
The main thread is from time to time delaying the tcp send because it is busy doing other things. not much, just a 50 ms... but for me in this application even 5 ms delay is a lot. so my idea was to put the tcp server on a different core so it is not affected by the other things going on on the main thread. this obviously didnt work as i expected. I found a extensive post on stackoverflow with also links to the official documentation that states that the tcp server should stay on the main thread as it could give unexpected results. my ultimate goal is to have a TCP server running that is not affected by anything that happens on the GUI o other modules of the main thread.. if it has its own core even better. But python is giving me a hard time on this...
as for chat GPT, yes i agree with you and my opinion is the same. but after having found results online that state that it is possible, i tried to give it a shot. unfortunately it did not work in this case and gave wrong information.
thanks for your help
@Igor86
IF you are saying you have a main thread which has to act as a TCP server as well as other things, and IF you are right that a TCP server should only stay on main thread, then the thing to move into its own thread is the "because it is busy doing other things. not much, just a 50 ms... but for me in this application even 5 ms delay is a lot", so that the main/TCP server thread remains responsive.