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. threads and created objects
Forum Updated to NodeBB v4.3 + New Features

threads and created objects

Scheduled Pinned Locked Moved Solved General and Desktop
26 Posts 4 Posters 3.4k 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.
  • SGaistS SGaist

    Object belonging and thread affinity are different things.

    The message you had was because the destruction happened in the main thread.

    mzimmersM Offline
    mzimmersM Offline
    mzimmers
    wrote on last edited by
    #11

    @SGaist said in threads and created objects:

    Object belonging and thread affinity are different things.

    I didn't realize that, but OK.

    The message you had was because the destruction happened in the main thread.

    So, how is this changed by creating worker on the heap?

    1 Reply Last reply
    0
    • SGaistS SGaist

      Object belonging and thread affinity are different things.

      The message you had was because the destruction happened in the main thread.

      Christian EhrlicherC Offline
      Christian EhrlicherC Offline
      Christian Ehrlicher
      Lifetime Qt Champion
      wrote on last edited by
      #12

      @SGaist said in threads and created objects:

      The message you had was because the destruction happened in the main thread.

      Correct, I read it the other way and thought the timer was still in the main thread and was destructed in the other thread :)

      Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
      Visit the Qt Academy at https://academy.qt.io/catalog

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

        Your object on the stack gets destroyed at the end of the current scope.

        Moving it on the heap gets it out of that scope, but then it's your duty to delete it properly. Which you do by connecting the deleteLater slot to the finished signal.

        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
        3
        • SGaistS SGaist

          Object belonging and thread affinity are different things.

          The message you had was because the destruction happened in the main thread.

          mzimmersM Offline
          mzimmersM Offline
          mzimmers
          wrote on last edited by
          #14

          @SGaist said in threads and created objects:

          Object belonging and thread affinity are different things.

          I need to pursue this a bit further. So, if I have an object (my worker object) that I move to another thread, is it true that anything created within that object prior to the move "belongs" to the original thread?

          Specifically, my worker object has a member object m_serial. Presumably this object belongs to the original thread. After worker is moved, when this object creates something (like a QSerialPort), this "belongs" to the worker thread. When the worker thread does a write on it, I get the timer error. Is this because m_serial belongs to the original thread, but its QSerialPort belongs to the worker thread?

          And if I have this right, is the solution that the worker thread would create its objects in start(), instead of having member objects?

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

            @mzimmers said in threads and created objects:

            I need to pursue this a bit further. So, if I have an object (my worker object) that I move to another thread, is it true that anything created within that object prior to the move "belongs" to the original thread?

            If it's a QObject that is properly parented, it will move with it. Note that classes like QTcpSocket must be created in the new thread. You can however pass the descriptor like shown in the threaded QTcpSocket/Server example.

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

            kshegunovK mzimmersM 2 Replies Last reply
            1
            • SGaistS SGaist

              @mzimmers said in threads and created objects:

              I need to pursue this a bit further. So, if I have an object (my worker object) that I move to another thread, is it true that anything created within that object prior to the move "belongs" to the original thread?

              If it's a QObject that is properly parented, it will move with it. Note that classes like QTcpSocket must be created in the new thread. You can however pass the descriptor like shown in the threaded QTcpSocket/Server example.

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

              @SGaist said in threads and created objects:

              If it's a QObject that is properly patented, it will move with it. Note that classes like QTcoSocket must be created in the new thread. You can however pass the descriptor like shown in the threaded QTcpSocket/Server example.

              Actually a comment on that. Sockets that haven't been opened/bound can still be moved normally, however I agree it's a bad practice to depend on the actual implementation.

              Read and abide by the Qt Code of Conduct

              1 Reply Last reply
              1
              • SGaistS SGaist

                @mzimmers said in threads and created objects:

                I need to pursue this a bit further. So, if I have an object (my worker object) that I move to another thread, is it true that anything created within that object prior to the move "belongs" to the original thread?

                If it's a QObject that is properly parented, it will move with it. Note that classes like QTcpSocket must be created in the new thread. You can however pass the descriptor like shown in the threaded QTcpSocket/Server example.

                mzimmersM Offline
                mzimmersM Offline
                mzimmers
                wrote on last edited by
                #17

                @SGaist said in threads and created objects:

                If it's a QObject that is properly patented, it will move with it.

                This is my current creation:

                class Worker : public QObject
                {
                    Q_OBJECT
                private:
                    SerialPort m_serial;
                ...
                SerialPort::SerialPort(QObject *parent) : QObject (parent)
                {
                ...
                

                Note that classes like QTcoSocket must be created in the new thread.

                But not in the c'tor, correct? Because that is called prior to the thread move, so it would pertain to the original thread?

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

                  I fixed the typo of parented (damn autocorrect...)

                  Yes, m_serial will not be moved.

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

                  mzimmersM 1 Reply Last reply
                  2
                  • SGaistS SGaist

                    I fixed the typo of parented (damn autocorrect...)

                    Yes, m_serial will not be moved.

                    mzimmersM Offline
                    mzimmersM Offline
                    mzimmers
                    wrote on last edited by mzimmers
                    #19

                    @SGaist said in threads and created objects:

                    I fixed the typo of parented (damn autocorrect...

                    Well, while you're at it..."QTcoSocket?"

                    kshegunovK SGaistS 2 Replies Last reply
                    0
                    • mzimmersM mzimmers

                      @SGaist said in threads and created objects:

                      I fixed the typo of parented (damn autocorrect...

                      Well, while you're at it..."QTcoSocket?"

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

                      If you want the QObjects to to be moved alongside with their parent to another thread, then you must pass them the parent. No parent, no way Qt to know whether the object's supposed to be moved.

                      Read and abide by the Qt Code of Conduct

                      mzimmersM 1 Reply Last reply
                      0
                      • mzimmersM mzimmers

                        @SGaist said in threads and created objects:

                        I fixed the typo of parented (damn autocorrect...

                        Well, while you're at it..."QTcoSocket?"

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

                        @mzimmers said in threads and created objects:

                        @SGaist said in threads and created objects:

                        I fixed the typo of parented (damn autocorrect...

                        Well, while you're at it..."QTcoSocket?"

                        Argle........ Done

                        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
                        0
                        • kshegunovK kshegunov

                          If you want the QObjects to to be moved alongside with their parent to another thread, then you must pass them the parent. No parent, no way Qt to know whether the object's supposed to be moved.

                          mzimmersM Offline
                          mzimmersM Offline
                          mzimmers
                          wrote on last edited by mzimmers
                          #22

                          @kshegunov I don't know how to do that in this case. If my SerialPort object is defined:

                          class SerialPort : public QObject
                          {
                              Q_OBJECT
                          public:
                              explicit SerialPort(Worker *parent = nullptr);
                          ...
                          SerialPort::SerialPort(Worker *parent) : QObject(parent)
                          

                          Then how do I declare an instance of SerialPort in my worker object? If I do it like this:

                              SerialPort m_serial;
                          

                          Then it doesn't seem to get moved.

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

                            The usual: pointer and allocate it in the constructor with a parent.

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

                            mzimmersM 1 Reply Last reply
                            0
                            • SGaistS SGaist

                              The usual: pointer and allocate it in the constructor with a parent.

                              mzimmersM Offline
                              mzimmersM Offline
                              mzimmers
                              wrote on last edited by
                              #24

                              @SGaist OK, thanks. I had (incorrectly) inferred from kshegunov's post that it somehow could be done as an ordinary member variable.

                              kshegunovK 1 Reply Last reply
                              0
                              • mzimmersM mzimmers

                                @SGaist OK, thanks. I had (incorrectly) inferred from kshegunov's post that it somehow could be done as an ordinary member variable.

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

                                @mzimmers No the inference is correct. This shall work, shan't it?

                                class Worker : public QObject
                                {
                                    Q_OBJECT
                                public:
                                    Worker();
                                private:
                                    SerialPort m_serial;
                                };
                                
                                Worker::Worker()
                                    : m_serial(this)
                                {
                                }
                                

                                Read and abide by the Qt Code of Conduct

                                mzimmersM 1 Reply Last reply
                                2
                                • kshegunovK kshegunov

                                  @mzimmers No the inference is correct. This shall work, shan't it?

                                  class Worker : public QObject
                                  {
                                      Q_OBJECT
                                  public:
                                      Worker();
                                  private:
                                      SerialPort m_serial;
                                  };
                                  
                                  Worker::Worker()
                                      : m_serial(this)
                                  {
                                  }
                                  
                                  mzimmersM Offline
                                  mzimmersM Offline
                                  mzimmers
                                  wrote on last edited by
                                  #26

                                  @kshegunov well...yes it does. I was missing the " : m_serial(this)" clause. Thanks!

                                  1 Reply Last reply
                                  1

                                  • Login

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