The default run() implementation in QThread runs an event loop for you, the equivalent of: class GenericThread(QThread): def run(self, *args): self.exec_() The important thing about an event loop is that it allows objects owned by the thread to receive events on their slots, which will be executed in that thread. Those objects are just QObjects, … Read more
Take a look at Signals and slots across threads. If you always use signals and slots to communicate with the worker thread, Qt handles the moveToThread for you if it’s needed and you used the correct connection. Edit: I would guess the article’s author was seeing his problem since he was calling start in the … Read more
The Safe Thread In C++, the proper design of a class is such that the instance can be safely destroyed at any time. Almost all Qt classes act that way, but QThread doesn’t. Here’s the class you should be using instead: // Thread.hpp #include <QThread> public Thread : class QThread { Q_OBJECT using QThread::run; // … Read more
As I commented (further information in the link) you are doing it wrong : You are mixing the object holding thread data with another object (responsible of doIt()). They should be separated. There is no need to subclass QThread in your case. Worse, you are overriding the run method without any consideration of what it … Read more
QCoreApplication QMetaCallEvent Compression Every queued slot call ends up in the posting of a QMetaCallEvent to the target object. The event contains the sender object, the signal id, the slot index, and packaged call parameters. On Qt 5, the signal id generally doesn’t equal the value returned by QMetaObject::signalIndex(): it is an index computed as … Read more
The problem is solved by passing him as a parent to self. You must change: thread = QThread() to: thread = QThread(parent=self)
The applicable Qt APIs depend on what is the functionality of the thread-safe method. Let’s cover the circumstances from the most general to most specific. Signals The bodies of signals are generated by the moc tool and are thread-safe. Corollary 1: All directly-connected slots/functors must be thread-safe: doing otherwise breaks the contract of a signal. … Read more
You won’t see much of a difference unless you’re working with objects having different thread affinities. Let’s say you have QObjects A and B and they’re both attached to different threads. A has a signal called somethingChanged() and B has a slot called handleChange(). If you use a direct connection connect( A, SIGNAL(somethingChanged()), B, SLOT(handleChange()), … Read more
Here is a working example of a separate worker thread which can send and receive signals to allow it to communicate with a GUI. I made two simple buttons, one which starts a long calculation in a separate thread, and one which immediately terminates the calculation and resets the worker thread. Forcibly terminating a thread … Read more
About the only thing I can think of to add is to further state that QObjects have an affinity with a single thread. This is usually the thread that creates the QObject. So if you create a QObject in the app’s main thread and want to use it in another thread, you need to use … Read more