Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Issue with QThread subclass and signal/slots
Forum Updated to NodeBB v4.3 + New Features

Issue with QThread subclass and signal/slots

Scheduled Pinned Locked Moved Solved General and Desktop
qthread
21 Posts 6 Posters 4.2k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Joel BodenmannJ Offline
    Joel BodenmannJ Offline
    Joel Bodenmann
    wrote on last edited by
    #1

    I'm currently working on a small tool which allows to run a regex search on all files within a directory (of course with tons of options).
    My architecture mainly consists of the following classes:

    • Dialog (inherits QWidget)
    • Controller (inherits QThread)
    • Indexer (inherits QThread)
    • Worker (inherits QThread)

    There's a button in the Dialog that allows launching a search performed by the Controller. The reason that Controller is running in a separate thread is to keep the GUI responsive.
    Once the controller is asked to do it's job (by Dialog calling Controller::find()) it will launch an Indexer thread. The Indexer goes through the file system and emits the newFile() signal for each file that matches the search criteria and should therefore be searched by running the regex on it.
    The Controller connects to the Indexer::newFile() signal and launches one Worker for each time the slot is being executed which results in having one worker per file. There's a Worker pool that Controller manages to be able to set some upper limit for the number of Workers running in parallel.

    Here's all relevant code pasted:

    • worker.h
    • worker.cpp
    • indexer.h
    • indexer.cpp
    • controller.h
    • controller.cpp

    If I run this (by calling Controller::find() from the GUI) I can see that the Indexer finishes very quickly (I get "Indexer::run(): finished" printed in the application output immediately) but the corresponding Controller::indexerFinished() slot is only invoked after a couple of seconds.
    The GUI itself is supposed to display the results. Hence I forward the resultReady() signal of each Worker to the corresponding Controllers signal which the GUI listens too. I can observe the same behavior there: While I can confirm that the Workers are emitting the resultReady signal immediately but the GUI only receives them after/when the Controller::indexerFinished() slot is being executed.

    Did I screw something up with the reimplementation of QThread::run() in the Controller class? I didn't call exec() in the Indexer::run() and Worker::run() methods as I don't need an event loop inside those threads.
    I'd appreciate any help on this.

    Industrial process automation software: https://simulton.com
    Embedded Graphics & GUI library: https://ugfx.io

    kshegunovK 1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

      I don't see anything wrong with the implementation. Did you try to benchmark these classes ?

      By the way, why not use QtConcurrent ? Looks like a good use case got it here.

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      1
      • Joel BodenmannJ Joel Bodenmann

        I'm currently working on a small tool which allows to run a regex search on all files within a directory (of course with tons of options).
        My architecture mainly consists of the following classes:

        • Dialog (inherits QWidget)
        • Controller (inherits QThread)
        • Indexer (inherits QThread)
        • Worker (inherits QThread)

        There's a button in the Dialog that allows launching a search performed by the Controller. The reason that Controller is running in a separate thread is to keep the GUI responsive.
        Once the controller is asked to do it's job (by Dialog calling Controller::find()) it will launch an Indexer thread. The Indexer goes through the file system and emits the newFile() signal for each file that matches the search criteria and should therefore be searched by running the regex on it.
        The Controller connects to the Indexer::newFile() signal and launches one Worker for each time the slot is being executed which results in having one worker per file. There's a Worker pool that Controller manages to be able to set some upper limit for the number of Workers running in parallel.

        Here's all relevant code pasted:

        • worker.h
        • worker.cpp
        • indexer.h
        • indexer.cpp
        • controller.h
        • controller.cpp

        If I run this (by calling Controller::find() from the GUI) I can see that the Indexer finishes very quickly (I get "Indexer::run(): finished" printed in the application output immediately) but the corresponding Controller::indexerFinished() slot is only invoked after a couple of seconds.
        The GUI itself is supposed to display the results. Hence I forward the resultReady() signal of each Worker to the corresponding Controllers signal which the GUI listens too. I can observe the same behavior there: While I can confirm that the Workers are emitting the resultReady signal immediately but the GUI only receives them after/when the Controller::indexerFinished() slot is being executed.

        Did I screw something up with the reimplementation of QThread::run() in the Controller class? I didn't call exec() in the Indexer::run() and Worker::run() methods as I don't need an event loop inside those threads.
        I'd appreciate any help on this.

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by kshegunov
        #3

        I saw a couple of race conditions. :)
        Now I want to be sure of something before we continue on:
        You do realize that every slot of the QThread subclass is executed in the thread the QThread object lives in, correct?
        This would include FindController::indexerFinished, FindController::processFile, FindController::resultReady and so on.

        In that same spirit, connect(worker, &FindWorker::finished, [=]{ workerFinished(worker); }); will make your workerFinished function be executed in the worker's thread (FindWorker class), which is a race condition as you touch the common data from that method.

        And a minor one that I spotted:

        void FindWorker::run()
        {
            // Open the file
            do {
            // ...
            } while (!line.isNull() && !_stopRequested); //< Reading `_stopRequested` while not protected
        }
        
        void FindWorker::requestStop()
        {
            static QMutex mutex; //< Takes care of write protection, but not of reading it in another context. :)
         
            mutex.lock();
            _stopRequested = true;
            mutex.unlock();
        }
        

        For that thing you ought to use requestInterruption() and isInterruptionRequested() from QThread instead.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply
        4
        • SGaistS Offline
          SGaistS Offline
          SGaist
          Lifetime Qt Champion
          wrote on last edited by
          #4

          @kshegunov Nice catches ! I did miss some interesting cases...

          If you insist on keeping _stopRequested , you should make it an std::atomic otherwise, you might get surprising optimisation depending on how you access it.

          Interested in AI ? www.idiap.ch
          Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

          kshegunovK 1 Reply Last reply
          1
          • Joel BodenmannJ Offline
            Joel BodenmannJ Offline
            Joel Bodenmann
            wrote on last edited by
            #5

            @kshegunov said in Issue with QThread subclass and signal/slots:

            You do realize that every slot of the QThread subclass is executed in the thread the QThread object lives in, correct?

            Nope, I don't. Or at least, I didn't until know.
            I thought that was only the case if Qt::DirectConnection is used. The way I understand the documentation, the slot should be executed in the thread that "owns the method" if Qt::QueuedConnection is used, no? What am I missing?

            However, I can confirm that that's what's happening. That's why the GUI is blocked: I managed to prove that all of the heavy code in FindController is being executed in the GUI thread.

            Regarding the mutex stuff: I assume (and that might be the problem) that reading a boolen is an atomic operation anyway. At least that's how it works in my world (embedded stuff). Is this different here? Am I missing something completely obvious?
            Anyway, I'm definitely checking out QThread::requestInterruption() and QThread::isInterruptionRequested(). That seems like a decent choice :p

            @SGaist: I don't insist on anything but doing everything the right way. So if there's a better way (which there seems to be) I'm certainly going to choose that one.

            Industrial process automation software: https://simulton.com
            Embedded Graphics & GUI library: https://ugfx.io

            Joel BodenmannJ VRoninV 2 Replies Last reply
            0
            • SGaistS SGaist

              @kshegunov Nice catches ! I did miss some interesting cases...

              If you insist on keeping _stopRequested , you should make it an std::atomic otherwise, you might get surprising optimisation depending on how you access it.

              kshegunovK Offline
              kshegunovK Offline
              kshegunov
              Moderators
              wrote on last edited by
              #6

              @SGaist said in Issue with QThread subclass and signal/slots:

              Nice catches !

              Thanks! :D

              If you insist on keeping _stopRequested , you should make it an std::atomic otherwise, you might get surprising optimisation depending on how you access it.

              This is what requestInterruption does internally, so I do advice making use of the already provided API. :)

              Read and abide by the Qt Code of Conduct

              SGaistS 1 Reply Last reply
              0
              • Joel BodenmannJ Joel Bodenmann

                @kshegunov said in Issue with QThread subclass and signal/slots:

                You do realize that every slot of the QThread subclass is executed in the thread the QThread object lives in, correct?

                Nope, I don't. Or at least, I didn't until know.
                I thought that was only the case if Qt::DirectConnection is used. The way I understand the documentation, the slot should be executed in the thread that "owns the method" if Qt::QueuedConnection is used, no? What am I missing?

                However, I can confirm that that's what's happening. That's why the GUI is blocked: I managed to prove that all of the heavy code in FindController is being executed in the GUI thread.

                Regarding the mutex stuff: I assume (and that might be the problem) that reading a boolen is an atomic operation anyway. At least that's how it works in my world (embedded stuff). Is this different here? Am I missing something completely obvious?
                Anyway, I'm definitely checking out QThread::requestInterruption() and QThread::isInterruptionRequested(). That seems like a decent choice :p

                @SGaist: I don't insist on anything but doing everything the right way. So if there's a better way (which there seems to be) I'm certainly going to choose that one.

                Joel BodenmannJ Offline
                Joel BodenmannJ Offline
                Joel Bodenmann
                wrote on last edited by
                #7

                @Joel-Bodenmann said:

                Regarding the mutex stuff: I assume (and that might be the problem) that reading a boolen is an atomic operation anyway. At least that's how it works in my world (embedded stuff). Is this different here? Am I missing something completely obvious?

                Edit: Thinking about this I just realized that I'm dealing with a multi-core system here, so things "are different" than on my beloved microcontrollers :p

                Industrial process automation software: https://simulton.com
                Embedded Graphics & GUI library: https://ugfx.io

                1 Reply Last reply
                0
                • Joel BodenmannJ Joel Bodenmann

                  @kshegunov said in Issue with QThread subclass and signal/slots:

                  You do realize that every slot of the QThread subclass is executed in the thread the QThread object lives in, correct?

                  Nope, I don't. Or at least, I didn't until know.
                  I thought that was only the case if Qt::DirectConnection is used. The way I understand the documentation, the slot should be executed in the thread that "owns the method" if Qt::QueuedConnection is used, no? What am I missing?

                  However, I can confirm that that's what's happening. That's why the GUI is blocked: I managed to prove that all of the heavy code in FindController is being executed in the GUI thread.

                  Regarding the mutex stuff: I assume (and that might be the problem) that reading a boolen is an atomic operation anyway. At least that's how it works in my world (embedded stuff). Is this different here? Am I missing something completely obvious?
                  Anyway, I'm definitely checking out QThread::requestInterruption() and QThread::isInterruptionRequested(). That seems like a decent choice :p

                  @SGaist: I don't insist on anything but doing everything the right way. So if there's a better way (which there seems to be) I'm certainly going to choose that one.

                  VRoninV Offline
                  VRoninV Offline
                  VRonin
                  wrote on last edited by
                  #8

                  @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                  The way I understand the documentation, the slot should be executed in the thread that "owns the method"

                  Correct but QThread is not a thread, it's a wrapper around it. A QThread object lives in the thread that creates it and all methods are owned by that thread, not the one spawned inside QThread. This is a common misconception, the docs are really not clear on this point. Take a look at this blog post

                  "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                  ~Napoleon Bonaparte

                  On a crusade to banish setIndexWidget() from the holy land of Qt

                  Joel BodenmannJ 1 Reply Last reply
                  6
                  • kshegunovK kshegunov

                    @SGaist said in Issue with QThread subclass and signal/slots:

                    Nice catches !

                    Thanks! :D

                    If you insist on keeping _stopRequested , you should make it an std::atomic otherwise, you might get surprising optimisation depending on how you access it.

                    This is what requestInterruption does internally, so I do advice making use of the already provided API. :)

                    SGaistS Offline
                    SGaistS Offline
                    SGaist
                    Lifetime Qt Champion
                    wrote on last edited by
                    #9

                    @kshegunov said in Issue with QThread subclass and signal/slots:

                    This is what requestInterruption does internally, so I do advice making use of the already provided API. :)

                    It does some additional checks regarding the running status of the thread. But rest assured, I do agree that this is a the API to use.

                    Interested in AI ? www.idiap.ch
                    Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                    1 Reply Last reply
                    2
                    • VRoninV VRonin

                      @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                      The way I understand the documentation, the slot should be executed in the thread that "owns the method"

                      Correct but QThread is not a thread, it's a wrapper around it. A QThread object lives in the thread that creates it and all methods are owned by that thread, not the one spawned inside QThread. This is a common misconception, the docs are really not clear on this point. Take a look at this blog post

                      Joel BodenmannJ Offline
                      Joel BodenmannJ Offline
                      Joel Bodenmann
                      wrote on last edited by
                      #10

                      @VRonin said in Issue with QThread subclass and signal/slots:

                      Correct but QThread is not a thread, it's a wrapper around it. A QThread object lives in the thread that creates it and all methods are owned by that thread, not the one spawned inside QThread. This is a common misconception, the docs are really not clear on this point. Take a look at this blog post

                      That's certainly an interesting read. However, I feel like the following information could use a bit more emphasis:

                      By the way, one extremely important thing to note here is that you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance.

                      Maybe it's just me but that seems like a very dirty pit to fall into.

                      Anyway, I'll rearrange things tonight and get back to you guys. Thanks for the help - much appreciated!

                      Industrial process automation software: https://simulton.com
                      Embedded Graphics & GUI library: https://ugfx.io

                      kshegunovK 1 Reply Last reply
                      0
                      • Joel BodenmannJ Joel Bodenmann

                        @VRonin said in Issue with QThread subclass and signal/slots:

                        Correct but QThread is not a thread, it's a wrapper around it. A QThread object lives in the thread that creates it and all methods are owned by that thread, not the one spawned inside QThread. This is a common misconception, the docs are really not clear on this point. Take a look at this blog post

                        That's certainly an interesting read. However, I feel like the following information could use a bit more emphasis:

                        By the way, one extremely important thing to note here is that you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance.

                        Maybe it's just me but that seems like a very dirty pit to fall into.

                        Anyway, I'll rearrange things tonight and get back to you guys. Thanks for the help - much appreciated!

                        kshegunovK Offline
                        kshegunovK Offline
                        kshegunov
                        Moderators
                        wrote on last edited by kshegunov
                        #11

                        @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                        Maybe it's just me but that seems like a very dirty pit to fall into.

                        That one is wrong. :)
                        You just have to give the worker object as parent to the objects you create (be it stack or heap). They'll be moved by Qt to the correct thread when the parent (i.e. the worker) is moved.

                        Read and abide by the Qt Code of Conduct

                        J.HilkJ 1 Reply Last reply
                        1
                        • kshegunovK kshegunov

                          @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                          Maybe it's just me but that seems like a very dirty pit to fall into.

                          That one is wrong. :)
                          You just have to give the worker object as parent to the objects you create (be it stack or heap). They'll be moved by Qt to the correct thread when the parent (i.e. the worker) is moved.

                          J.HilkJ Offline
                          J.HilkJ Offline
                          J.Hilk
                          Moderators
                          wrote on last edited by
                          #12

                          @kshegunov said in Issue with QThread subclass and signal/slots:

                          @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                          Maybe it's just me but that seems like a very dirty pit to fall into.

                          That one is wrong. :)
                          You just have to give the worker object as parent to the objects you create (be it stack or heap). They'll be moved by Qt to the correct thread when the parent (i.e. the worker) is moved.

                          correct me if I'm wrong, but that's only true for objects that have QObject as baseclass, right?


                          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                          Q: What's that?
                          A: It's blue light.
                          Q: What does it do?
                          A: It turns blue.

                          kshegunovK 1 Reply Last reply
                          1
                          • J.HilkJ J.Hilk

                            @kshegunov said in Issue with QThread subclass and signal/slots:

                            @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                            Maybe it's just me but that seems like a very dirty pit to fall into.

                            That one is wrong. :)
                            You just have to give the worker object as parent to the objects you create (be it stack or heap). They'll be moved by Qt to the correct thread when the parent (i.e. the worker) is moved.

                            correct me if I'm wrong, but that's only true for objects that have QObject as baseclass, right?

                            kshegunovK Offline
                            kshegunovK Offline
                            kshegunov
                            Moderators
                            wrote on last edited by kshegunov
                            #13

                            @J.Hilk said in Issue with QThread subclass and signal/slots:

                            correct me if I'm wrong, but that's only true for objects that have QObject as baseclass, right?

                            Absolutely right. Then let me respond with a counter question, what is thread affinity (i.e. in what thread does an object live in) if it's not derived from QObject? ;)

                            Read and abide by the Qt Code of Conduct

                            J.HilkJ 1 Reply Last reply
                            1
                            • kshegunovK kshegunov

                              @J.Hilk said in Issue with QThread subclass and signal/slots:

                              correct me if I'm wrong, but that's only true for objects that have QObject as baseclass, right?

                              Absolutely right. Then let me respond with a counter question, what is thread affinity (i.e. in what thread does an object live in) if it's not derived from QObject? ;)

                              J.HilkJ Offline
                              J.HilkJ Offline
                              J.Hilk
                              Moderators
                              wrote on last edited by
                              #14

                              @kshegunov

                              true,

                              mmh, what I could think of is maybe (member)QDataStream and QFile?


                              Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                              Q: What's that?
                              A: It's blue light.
                              Q: What does it do?
                              A: It turns blue.

                              kshegunovK 1 Reply Last reply
                              0
                              • J.HilkJ J.Hilk

                                @kshegunov

                                true,

                                mmh, what I could think of is maybe (member)QDataStream and QFile?

                                kshegunovK Offline
                                kshegunovK Offline
                                kshegunov
                                Moderators
                                wrote on last edited by kshegunov
                                #15

                                Both of which are QFile is a QObject :D

                                Read and abide by the Qt Code of Conduct

                                J.HilkJ 1 Reply Last reply
                                0
                                • kshegunovK kshegunov

                                  Both of which are QFile is a QObject :D

                                  J.HilkJ Offline
                                  J.HilkJ Offline
                                  J.Hilk
                                  Moderators
                                  wrote on last edited by
                                  #16

                                  @kshegunov
                                  are you sure? it has a QIODevice as a member (pointer) variable and that may or may not be derived from QObject, depending on

                                  #ifndef QT_NO_QOBJECT
                                      : public QObject
                                  #endif
                                  

                                  But I don't see saynthing in the code pointing to QObject.
                                  https://code.woboq.org/qt5/qtbase/src/corelib/serialization/qdatastream.h.html


                                  Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                                  Q: What's that?
                                  A: It's blue light.
                                  Q: What does it do?
                                  A: It turns blue.

                                  kshegunovK 1 Reply Last reply
                                  0
                                  • J.HilkJ J.Hilk

                                    @kshegunov
                                    are you sure? it has a QIODevice as a member (pointer) variable and that may or may not be derived from QObject, depending on

                                    #ifndef QT_NO_QOBJECT
                                        : public QObject
                                    #endif
                                    

                                    But I don't see saynthing in the code pointing to QObject.
                                    https://code.woboq.org/qt5/qtbase/src/corelib/serialization/qdatastream.h.html

                                    kshegunovK Offline
                                    kshegunovK Offline
                                    kshegunov
                                    Moderators
                                    wrote on last edited by
                                    #17

                                    @J.Hilk said in Issue with QThread subclass and signal/slots:

                                    are you sure?

                                    Yes, of course taking in mind that I rushed a bit and qobject-ified the data stream. Otherwise the QIODevice is a QObject for sure. That macro shouldn't bother you, it's there for other reasons (like QtScript). Your QIODevice c++ objects are all QObjects.

                                    Read and abide by the Qt Code of Conduct

                                    1 Reply Last reply
                                    1
                                    • Joel BodenmannJ Offline
                                      Joel BodenmannJ Offline
                                      Joel Bodenmann
                                      wrote on last edited by
                                      #18

                                      Okay so I reorganized everything to use moveToThread() instead of subclassing QThread and everything is working as expected.
                                      The only thing that provided me with these two painful days was the fact that I didn't understand that slots of a QThread subclass are not executed in the new thread even though queued connections are used. I hope that this information will help others in the future.

                                      Thank you everybody for your help! As always: Much appreciated!

                                      Industrial process automation software: https://simulton.com
                                      Embedded Graphics & GUI library: https://ugfx.io

                                      JKSHJ 1 Reply Last reply
                                      3
                                      • Joel BodenmannJ Joel Bodenmann

                                        Okay so I reorganized everything to use moveToThread() instead of subclassing QThread and everything is working as expected.
                                        The only thing that provided me with these two painful days was the fact that I didn't understand that slots of a QThread subclass are not executed in the new thread even though queued connections are used. I hope that this information will help others in the future.

                                        Thank you everybody for your help! As always: Much appreciated!

                                        JKSHJ Offline
                                        JKSHJ Offline
                                        JKSH
                                        Moderators
                                        wrote on last edited by
                                        #19

                                        @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                                        The only thing that provided me with these two painful days was the fact that I didn't understand that slots of a QThread subclass are not executed in the new thread even though queued connections are used.

                                        Hi @Joel-Bodenmann, I'm thinking of improving the QThread documentation to help developers avoid such a pitfall in the future.

                                        Your particular scenario was mentioned in https://doc.qt.io/qt-5/qthread.html :

                                        "It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots and invoked methods will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread."

                                        However, that section is quite buried in the documentation.

                                        Can you think of a way to update the documentation, so that someone else in your position would be more likely to read and understand it?

                                        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                                        kshegunovK 1 Reply Last reply
                                        4
                                        • JKSHJ JKSH

                                          @Joel-Bodenmann said in Issue with QThread subclass and signal/slots:

                                          The only thing that provided me with these two painful days was the fact that I didn't understand that slots of a QThread subclass are not executed in the new thread even though queued connections are used.

                                          Hi @Joel-Bodenmann, I'm thinking of improving the QThread documentation to help developers avoid such a pitfall in the future.

                                          Your particular scenario was mentioned in https://doc.qt.io/qt-5/qthread.html :

                                          "It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots and invoked methods will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread."

                                          However, that section is quite buried in the documentation.

                                          Can you think of a way to update the documentation, so that someone else in your position would be more likely to read and understand it?

                                          kshegunovK Offline
                                          kshegunovK Offline
                                          kshegunov
                                          Moderators
                                          wrote on last edited by
                                          #20

                                          A QThread object manages one thread of control within the program. QThreads begin executing in run(). By default, run() starts the event loop by calling exec() and runs a Qt event loop inside the thread.

                                          To:

                                          A QThread object is not a thread itself, instead it manages one thread of control within the program. This also implies that QThread objects, as any QObject, have a [thread affinity](url to affinity) initially determined at the time they are created and their slots are queued for execution according to their affinity. /You may want to rephrase it a bit better though/
                                          [... continue on with the how ...] QThreads begin executing in run(). By default, run() starts the event loop by calling exec() and runs a Qt event loop inside the thread.

                                          Read and abide by the Qt Code of Conduct

                                          1 Reply Last reply
                                          0

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved