Yes, example 4 is exactly about sockets, it will work just fine with QTcpSocket, both the asynchronous API (signals, like in this example) and the synchronous API (waitFor...) (that's the benefit of being in a secondary thread, we can block without blocking the GUI).
I have an existing console-application that uses std:thread, to interface to the serial port (1st thread), can-bus (2nd thread), and a (3rd) logger thread that receives data from the other threads and writes to a file. Now I'd like to make the application into a GUI.. Would adding another std:thread for the Qt-Gui be easier, or should the app be written from scratch using Qt's multitasking (i.e. re-write the serial port and can-bus code to use QThread not std:thread)?
It is perfectly fine to have std::thread and QThread in the same process. You can certainly keep the existing std::thread code. If possible, you should use the main thread for the Qt GUI, rather than creating a separate std::thread for it. It'll be simpler. For passing the command line arguments, for instance. And to avoid issues the day you start using any Qt class from another thread (even a simple qDebug() in a thread created before the Qt GUI thread would make everything fail). So my recommendation is: move any work currently done by the main thread (if any) to a secondary thread, then use the main thread for Qt.
DirectConnection means that the thread emitting the signal, will be the one calling the slot. When doing this, there is a high risk of introducing data races, if the rest of the code in the receiver runs in a different thread. You'll need to protect the data accessed by the slot with a mutex (both in the slot, and in the rest of the code). And if you're going to run the receiver code in the emitter thread, what's the point in using a separate thread for the receiver? Overall, I strongly recommend against using DirectConnection in a multithreading context, unless you really know what you're doing and you have a good reason to bypass the whole idea of running receiver code in the receiver thread....
That's what it's all about, isn't it? You simply connect (in the main thread) to the signal from the QOject that belongs to another thread (for instance before the call to moveToThread(), if that's what you're using).
@@DavidFaure Yes, I have a class in which I create threads for the classes I need. One of them is an EventHandler that communicates with the GUI. And when I use the target: EventHandler I want to turn to the signal, I have an error. QQmlEngine: Illegal attempt to connect to EventHandler(0x5574065eed50) that is in a different thread than the QML engine QQmlApplicationEngine(0x7fff77edfac0. I don't understand what is causing this error.
@@BlinCT I guess the problem you're facing is that QML is even stricter than other facilities in Qt, and does not let you touch an object living in another thread at all, not even to connect to its signals. You could solve that by creating "proxy"/"trampoline" objects living in the main thread, connect those proxy objects to the backend in C++, and then using them from QML. (Beware of the implications regarding lifetime if you do so.)
Thank you very much for your video. The Qt Tcp socket runs in a thread to send and receive data. Is this OK with a method like example 4?👍
Yes, example 4 is exactly about sockets, it will work just fine with QTcpSocket, both the asynchronous API (signals, like in this example) and the synchronous API (waitFor...) (that's the benefit of being in a secondary thread, we can block without blocking the GUI).
Namaste brother your explanation on subject is good ...Thank you .
I have an existing console-application that uses std:thread, to interface to the serial port (1st thread), can-bus (2nd thread), and a (3rd) logger thread that receives data from the other threads and writes to a file.
Now I'd like to make the application into a GUI..
Would adding another std:thread for the Qt-Gui be easier, or should the app be written from scratch using Qt's multitasking (i.e. re-write the serial port and can-bus code to use QThread not std:thread)?
It is perfectly fine to have std::thread and QThread in the same process. You can certainly keep the existing std::thread code. If possible, you should use the main thread for the Qt GUI, rather than creating a separate std::thread for it. It'll be simpler. For passing the command line arguments, for instance. And to avoid issues the day you start using any Qt class from another thread (even a simple qDebug() in a thread created before the Qt GUI thread would make everything fail). So my recommendation is: move any work currently done by the main thread (if any) to a secondary thread, then use the main thread for Qt.
What if it was enough to just define the connection type as DirectConnection ?🤔 So don't need to avoid adding slots to QThread. thank you KDAB
DirectConnection means that the thread emitting the signal, will be the one calling the slot. When doing this, there is a high risk of introducing data races, if the rest of the code in the receiver runs in a different thread. You'll need to protect the data accessed by the slot with a mutex (both in the slot, and in the rest of the code). And if you're going to run the receiver code in the emitter thread, what's the point in using a separate thread for the receiver? Overall, I strongly recommend against using DirectConnection in a multithreading context, unless you really know what you're doing and you have a good reason to bypass the whole idea of running receiver code in the receiver thread....
I was hoping to see in this video how I can access the signal from another thread in the main GUI thread (
That's what it's all about, isn't it? You simply connect (in the main thread) to the signal from the QOject that belongs to another thread (for instance before the call to moveToThread(), if that's what you're using).
@@DavidFaure Yes, I have a class in which I create threads for the classes I need. One of them is an EventHandler that communicates with the GUI. And when I use the target: EventHandler I want to turn to the signal, I have an error. QQmlEngine: Illegal attempt to connect to EventHandler(0x5574065eed50) that is in a different thread than the QML engine QQmlApplicationEngine(0x7fff77edfac0. I don't understand what is causing this error.
@@BlinCT I guess the problem you're facing is that QML is even stricter than other facilities in Qt, and does not let you touch an object living in another thread at all, not even to connect to its signals. You could solve that by creating "proxy"/"trampoline" objects living in the main thread, connect those proxy objects to the backend in C++, and then using them from QML. (Beware of the implications regarding lifetime if you do so.)
Why you don't provide a minimal working example instead of only code snippets that can be confusing?