Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
After exit from a forked process I get QObject - Timers cannot be stopped from another thread
-
I'm writing a multi-process program in order to communicate with N esp devices with TCP sockets in Ubuntu. I decided to use process making N fork from the father and each child service one single connection and after the communication is finished it exit to the father that is waiting for all. It works perfectly in C++ but I need also a GUI and I decided to use QT.
In QT when a child exit() the stdderr get "QObject::~QObject: Timers cannot be stopped from another thread" and I don't know how to solve.
-
terminology, please....there is a difference between multi-process and multi threading. Which are you doing?
-
I'm writing a multi-process program.
-
and how are you spawning these children processes? Are you using the QProcess class or calling the POSIX fork() method?
BTW: the Qt way of doing this is NOT to create processes, but to multi-thread instead, and use the signal/slot mechanism to signal the main GUI thread when a worker has completed. Processes have a much higher degree of isolation than threads, so communicating with and controlling them is much more involved.
-
I'm creating process using the POSIX way, so making N fork and the parent wait for all them. I've done in this way because I need to have N different connection and each son has to talk in a different socket and was easier to have separate address spaces. But now I think that in Qt all is made using threads, I would like to not change all the code because that means to change also the code on esp module but if there's no way I'll have to use signal and slots with QThread.
Do you know where such error could come from?
The logic of the program is
MainWindow -> Dialog -> ServerThread -> Server -> A process for each connection -> when connection is finished QTimer cannot be stopped from another thread.
Thanks for your help
-
where is QTimer created? that thead/class should own and be responsible for stopping it. If you are forking() tasks with active timers and then trying to kill those timers in the parent task later on then all bets are off. I have no clue what might blow up in that scanario.
Really, I'm not sure that the Qt framework is fork() safe. I wonder whether the designers ever even considered that a Qt program may fork itself. On the surface it seems trivial, but Qt classes that interface with peripherals could be problematic if an app forks.
-
This post is deleted!
-
I solved using std c++11 thread class instead of making process with fork() , then I'll use QThread to pass my results on the GUI. Thanks for your help
-
Hi,
Out of curiosity, why are you mixing both type of thread technology ?
