I was going through the links
I got confused by some statements. In the first link, it says that
all of the functions in QThread were written and intended to be called from the creating thread, not the thread that QThread starts.
while it suggests to use moveToThread
to move an object to new thread, instead of subclassing QThread
. My question is:
The default implementation of run
method calls exec
, which creates an event loop, and when an object's thread affinity is changed using moveToThread
, all the slots
will be executed in the new thread, not on the creating thread, which is contradictory with the aforementioned intended use. Am I missing something?
Second question:
In the third link it is said
event queue is belong to thread instead of event loop, and it’s shared by all the event loops running in this thread.
My question is how there can be more than one event loop in a single thread ? What I understand is, event-loop loop through the event-queue, until exit
/terminate
is called, and processes each event
arrives on that queue. If this is true, one loop will never end (unless exit
/terminate
is called), how another can begin? Any sample code demonstrating it will be highly appreciated.
Yes, I think you're misunderstanding the concept of thread affinity (the thread on which an object is running).
Let's take an example with minimal code: -
Assuming this code has been created from an object whose thread affinity is the main thread, such as
QMainWindow
, the thread objectpThread
is running on the main thread; it's thread affinity is the main thread.In contrast, the
QObject
derivedMyObject
instance,myObj
, has been moved to the new threadpThread
. So, the thread affinity ofmyObj
is now the new thread.The "functions written for
QThread
" are still called directly from the main thread, as that's where it's running.Think of
QThread
as a thread controller object, rather than the thread itself. This is one of the reasons why it is often discouraged to inherit fromQThread
, unless you want to change howQThread
manages the underlying thread.I've not used this directly myself, but I'll try to explain this as I understand it. Perhaps someone else will be able to correct or confirm this. From the Qt Documentation for QEventLoop, it states: -
The signature from QEventLoop exec is: -
So if you pass in a set of flags, only these events would be handled. Now, as calling
exec()
starts the processing of events untilexit()
is called, you can create a local event loop that lets your program wait until one or more specific events occur.A second event loop is a local event loop within the main event loop, but as each event loop can process the whole event queue, which is shared by all event loops in a thread, it can be used to override event handling from the main event loop.
If you conceptualise an event loop as doing something like this (pseudo code): -
A 2nd event loop would then do this: -