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. [Solved] Qt::DirectConnection querries for multi threaded application?
Forum Updated to NodeBB v4.3 + New Features

[Solved] Qt::DirectConnection querries for multi threaded application?

Scheduled Pinned Locked Moved General and Desktop
9 Posts 3 Posters 5.5k Views 1 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.
  • CAD_codingC Offline
    CAD_codingC Offline
    CAD_coding
    wrote on last edited by
    #1

    Hi,
    I have some querries regarding how SIGNAL SLOT behave in multi threaded use case.
    Consider the following connection:

    @connect(parentObj, SIGNAL(sig1()), workerObj, SLOT(slot1()), Qt::DirectConnection);
    emit sig1();
    qDebug("SIGNAL1 emitted!");
    //workerObj is moved to different QThread.@

    Some querries:

    1. Is it guaranteed that qDebug() will be executed only after slot1() is executed?
    2. In which thread is slot1 executed, parentObj thread or workerObj thread?
    3. Instead of above code if I use
      @workerObj->slot1()@

    i.e. through parentObj thread is it correct/legal?

    1. Declaration of a SIGNAL requires a return type. So if the connection is Direct, is it guaranteed that the return value from the emit statement will be the same value as returned by the connected SLOT?

    @//parentObj class
    signals:
    bool sig2();

    //workerObj class
    slots:
    bool slot2();

    connect(parentObj, SIGNAL(sig2(bool)), workerObj, SLOT(slot2(bool)), Qt::DirectConnection);
    bool result = emit sig2();//is this legal?@

    1 Reply Last reply
    0
    • JKSHJ Offline
      JKSHJ Offline
      JKSH
      Moderators
      wrote on last edited by
      #2

      Hi,

      First, I recommend reading these 2 sections:

      • "QObject: Thread Affinity":http://qt-project.org/doc/qt-5/qobject.html#thread-affinity
      • "Qt::ConnectionType":http://qt-project.org/doc/qt-5/qt.html#ConnectionType-enum

      Second, remember that a QObject is not thread-safe. You are only allowed to access the object from one thread; you are not allowed to call its functions from a different thread.

      Third, to answer your questions:

      1. Technically, yes. But, you should NOT force Qt::DirectConnection when the object lives in a different thread.
      2. Qt::DirectConnection will cause the slot to be called in the thread that emits the signal.
      3. No.
      4. No. Direct vs. Queued only affects when and in which thread the slot is invoked. Direct connection does not link the slot's return value to the signal's return value.

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

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

        Hi,

        To add to JKSH, signals return value is void as explained "here":http://qt-project.org/doc/qt-5/signalsandslots.html#signals

        If you want to invoke a method on an object which returns something you should use Q_INVOKABLE and related methods

        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
        • CAD_codingC Offline
          CAD_codingC Offline
          CAD_coding
          wrote on last edited by
          #4

          Hi JKSH,

          Thank you for providing the links.

          bq. The slot is invoked immediately, when the signal is emitted.

          The documentation does not mention in which thread the slot will be executed. Perhaps it can be added for next build?

          I did not know that Qt::DirectConnection causes the slot to be executed in the emitting thread. Thanks for telling me that. This pretty much answers my 3 questions.

          Now in my use case I need to get a value from an object moved to a different thread. The value must be returned immediately similar to like a function return value. This is because this return value is required in the next line of code. How do I achieve this?

          Hi SGaist,

          Thanks for the information about signals. From the code in question:

          @bool result = emit sig2();@

          I need to get a return value from an object moved to a different thread.
          I am using result in next line, so the next line must be executed only after the slot is executed and return value obtained. Now how do I do this?
          My previous attempts with Qt::DirectConnection seems futile.

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

            Then have a look at the invokeMethod documentation and the Qt::BlockingQueuedConnection

            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
            • JKSHJ Offline
              JKSHJ Offline
              JKSH
              Moderators
              wrote on last edited by
              #6

              You're welcome :)

              The method SGaist mentioned is QMetaObject::invokeMethod().

              [quote]The documentation does not mention in which thread the slot will be executed. Perhaps it can be added for next build?[/quote]Done: https://codereview.qt-project.org/#patch,all,74441,2

              The Qt Project is run under Open Governance. If you see something that can be fixed/improved quickly, feel free to send a patch yourself! (See http://qt-project.org/wiki/Gerrit-Introduction for info) If you can't make your own patch, submit ideas/bug reports to http://bugreports.qt-project.org/ (reports in this forum will get buried)

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

              1 Reply Last reply
              0
              • CAD_codingC Offline
                CAD_codingC Offline
                CAD_coding
                wrote on last edited by
                #7

                @SGaist, Qt::BlockingQueuedConnection was exactly I was looking for. Silly of me for not looking at all the connection types.

                @JKSH now that I understand BlockingQueuedConnection I am unable to understand why anybody would be requiring to use invokeMethod()? SIGNAL and SLOT is so much more clean and easy to use.

                OK got it about the bug reporting. I will send the patch next time. :)

                1 Reply Last reply
                0
                • JKSHJ Offline
                  JKSHJ Offline
                  JKSH
                  Moderators
                  wrote on last edited by
                  #8

                  You can emit a signal too if you prefer. invokeMethod() is for cases where:

                  • You want to invoke a slot without creating a signal, and/or
                  • You want to retrieve the slot's return value.

                  I'm not sure that the signal/slot technique is always cleaner though :)
                  @
                  // Signal/slot technique
                  connect(this, SIGNAL(sig2()), workerObj, SLOT(slot2()), Qt::BlockingQueuedConnection);

                  emit sig2();

                  // invokeMethod() technique
                  QMetaObject::invokeMethod(workerObj, "slot2", Qt::BlockingQueuedConnection);
                  @

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

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

                    A third case for invokeMethod is calling a Q_INVOKABLE method which is not the same thing as a slot.

                    And I agree with JKSH, in this case I would rather go with invokeMethod which is cleaner logic and code wise.

                    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

                    • Login

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