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. QTimer and the thread of the Qt loop
Forum Updated to NodeBB v4.3 + New Features

QTimer and the thread of the Qt loop

Scheduled Pinned Locked Moved Unsolved General and Desktop
5 Posts 4 Posters 1.7k Views 3 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.
  • P Offline
    P Offline
    Pippin
    wrote on last edited by
    #1

    Hello,
    I was told in the past that if a QTimer is connected to a particular slot (that is called whenever the signal timeout() happens), that QTimer is still processed in the same thread that the Qt loop is. However, in order to verify that, I connected a QPushButton to another slot that calls QMessageBox::question(...) somewhere inside. When I triggered that slot, I was shocked to see that the QTimer kept on doing its work. But in this case, isn't the Qt loop "frozen" for as long as I don't close the QMessageBox? Isn't it blocked at my slot, waiting for QMessageBox::question(...) to return something?

    Thanks in advance for enlightening me.

    JKSHJ 1 Reply Last reply
    0
    • P Pippin

      Hello,
      I was told in the past that if a QTimer is connected to a particular slot (that is called whenever the signal timeout() happens), that QTimer is still processed in the same thread that the Qt loop is. However, in order to verify that, I connected a QPushButton to another slot that calls QMessageBox::question(...) somewhere inside. When I triggered that slot, I was shocked to see that the QTimer kept on doing its work. But in this case, isn't the Qt loop "frozen" for as long as I don't close the QMessageBox? Isn't it blocked at my slot, waiting for QMessageBox::question(...) to return something?

      Thanks in advance for enlightening me.

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

      @Pippin said in QTimer and the thread of the Qt loop:

      in this case, isn't the Qt loop "frozen" for as long as I don't close the QMessageBox? Isn't it blocked at my slot, waiting for QMessageBox::question(...) to return something?

      QMessageBox::question() blocks your calling function, but it also starts another event loop.

      This new event loop allows the QMessageBox to handle mouse events (so that you can click the buttons in the QMessageBox). It also allows the QTimer to continue working.

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

      VRoninV 1 Reply Last reply
      2
      • JKSHJ JKSH

        @Pippin said in QTimer and the thread of the Qt loop:

        in this case, isn't the Qt loop "frozen" for as long as I don't close the QMessageBox? Isn't it blocked at my slot, waiting for QMessageBox::question(...) to return something?

        QMessageBox::question() blocks your calling function, but it also starts another event loop.

        This new event loop allows the QMessageBox to handle mouse events (so that you can click the buttons in the QMessageBox). It also allows the QTimer to continue working.

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

        @JKSH said in QTimer and the thread of the Qt loop:

        This new event loops [...] allows the QTimer to continue working.

        I don't think it needs an event loop at all, just a running thread, for example:

        #include <QTimer>
        #include <QCoreApplication>
        int main(int argc, char *argv[])
        {
            QCoreApplication a(argc, argv);
            QTimer aTimer;
            aTimer.setInterval(1000);
            aTimer.setSingleShot(true);
            aTimer.start();
            while (true)
            {
                qDebug() << aTimer.remainingTime();
            }
        return 0;
        }
        

        works fine. the event loop is required only as a bridge between signals and slots

        "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

        JKSHJ 1 Reply Last reply
        0
        • VRoninV VRonin

          @JKSH said in QTimer and the thread of the Qt loop:

          This new event loops [...] allows the QTimer to continue working.

          I don't think it needs an event loop at all, just a running thread, for example:

          #include <QTimer>
          #include <QCoreApplication>
          int main(int argc, char *argv[])
          {
              QCoreApplication a(argc, argv);
              QTimer aTimer;
              aTimer.setInterval(1000);
              aTimer.setSingleShot(true);
              aTimer.start();
              while (true)
              {
                  qDebug() << aTimer.remainingTime();
              }
          return 0;
          }
          

          works fine. the event loop is required only as a bridge between signals and slots

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

          @VRonin said in QTimer and the thread of the Qt loop:

          the event loop is required only as a bridge between signals and slots

          That's right.

          The original question was: How could the QTimer's timeout() signal continue getting processed when QMessageBox::question() is blocking the thread?

          The answer is: Because the block is caused by a new event loop (started by QDialog::exec() if I'm not mistaken). This event loop processes the QTimer's signals, even though the calling function is still blocked.

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

          kshegunovK 1 Reply Last reply
          1
          • JKSHJ JKSH

            @VRonin said in QTimer and the thread of the Qt loop:

            the event loop is required only as a bridge between signals and slots

            That's right.

            The original question was: How could the QTimer's timeout() signal continue getting processed when QMessageBox::question() is blocking the thread?

            The answer is: Because the block is caused by a new event loop (started by QDialog::exec() if I'm not mistaken). This event loop processes the QTimer's signals, even though the calling function is still blocked.

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

            @JKSH said in QTimer and the thread of the Qt loop:

            started by QDialog::exec() if I'm not mistaken

            You're not. All the message box statics call QDialog::exec, which in turn calls QEventLoop::exec.

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply
            2

            • Login

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