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. Signal/Slot process order in function
Forum Updated to NodeBB v4.3 + New Features

Signal/Slot process order in function

Scheduled Pinned Locked Moved Solved General and Desktop
7 Posts 3 Posters 2.8k Views
  • 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.
  • S Offline
    S Offline
    samdol
    wrote on last edited by samdol
    #1

    Hi,

    I have been always wondering about the order of signal/slot processing order.
    For example,

    class AA
    {
        private: ...
    
        public: AA(){}
                funcAA()
                {
                    funcAA1();
                    emit funcAA1_finished_signal();
                    funcAA2();
                }
    }
    class BB
    {
       private: ...
    
       public: BB()
               {
                    AA* aa = new AA;
                    connect(aa, SIGNAL(funcAA1_finished_signal()), this, SLOT(funcBB()));
               }
       public slots:
               funcBB(){...}
    }
    

    If I run funcAA(), after finishing funcAA1(), does funcAA2() runs always after
    funcBB() has finished? or if funcBB() takes too long time to finish, does funcAA2()
    may start even before funcBB() finished?

    JonBJ 1 Reply Last reply
    0
    • S samdol

      Hi,

      I have been always wondering about the order of signal/slot processing order.
      For example,

      class AA
      {
          private: ...
      
          public: AA(){}
                  funcAA()
                  {
                      funcAA1();
                      emit funcAA1_finished_signal();
                      funcAA2();
                  }
      }
      class BB
      {
         private: ...
      
         public: BB()
                 {
                      AA* aa = new AA;
                      connect(aa, SIGNAL(funcAA1_finished_signal()), this, SLOT(funcBB()));
                 }
         public slots:
                 funcBB(){...}
      }
      

      If I run funcAA(), after finishing funcAA1(), does funcAA2() runs always after
      funcBB() has finished? or if funcBB() takes too long time to finish, does funcAA2()
      may start even before funcBB() finished?

      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #2

      @samdol
      I'll probably turn out to be wrong, but I can't resist stating my understanding which is that: [Qt] signals are synchronous. funcAA1_finished_signal() does not return till any/all slot handlers have completed.

      Right?

      And also, BTW, I read somewhere yesterday that signal handlers (slots) are executed in the order they were connected (to the same signal). As in, that is guaranteed, as opposed to "the order of execution is undefined" which I had presumed would be the case.

      VRoninV 1 Reply Last reply
      1
      • JonBJ JonB

        @samdol
        I'll probably turn out to be wrong, but I can't resist stating my understanding which is that: [Qt] signals are synchronous. funcAA1_finished_signal() does not return till any/all slot handlers have completed.

        Right?

        And also, BTW, I read somewhere yesterday that signal handlers (slots) are executed in the order they were connected (to the same signal). As in, that is guaranteed, as opposed to "the order of execution is undefined" which I had presumed would be the case.

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

        @JonB kinda right.

        • if you use Qt::DirectConnection or if sender and receiver of the signal are in the same thread and the connecion is automatic
          • 'emit <signal>' will not return until all slots are executed.
        • if you use Qt::QueuedConnection or if sender and receiver of the signal are in different threads and the connecion is automatic
          • 'emit <signal>' returns immediately and the slot is executed once control goes back to the event loop (or QCoreApplication::processEvents is called)
        • if multiple slots are connected to the same signal, the order of slot execution is the same as the order of connection

        "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

        JonBJ 1 Reply Last reply
        3
        • VRoninV VRonin

          @JonB kinda right.

          • if you use Qt::DirectConnection or if sender and receiver of the signal are in the same thread and the connecion is automatic
            • 'emit <signal>' will not return until all slots are executed.
          • if you use Qt::QueuedConnection or if sender and receiver of the signal are in different threads and the connecion is automatic
            • 'emit <signal>' returns immediately and the slot is executed once control goes back to the event loop (or QCoreApplication::processEvents is called)
          • if multiple slots are connected to the same signal, the order of slot execution is the same as the order of connection
          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by
          #4

          @VRonin
          I was only thinking of your cases #1 & #3. i.e. for #1 I don't have my own threads, so I was thinking only in single-thread context, where I understood them to be synchronous, as you confirm. That also applies to the OP's example.

          I do have one question about your code & explanation. Please bear in mind that I only use Qt from Python, I don't have the C++ code or macros to look through to discover this for myself. With that in mind, I want to understand the root of the distinction between your cases #1 & #2.

          You are saying "emit <signal> behaviour varies depending on sender/receiver being in same or different threads". Now, I believe I am correct in saying that in your C++ emit is a macro which expands to nothing at all. In which case in both cases the code simply expands to the function call in the source immediately after the emit. Since emit in itself does nothing at all in the code, how do you get that behavioural difference you describe? It's just a C function call, so it knows nothing about same or different threads?

          VRoninV 1 Reply Last reply
          0
          • JonBJ JonB

            @VRonin
            I was only thinking of your cases #1 & #3. i.e. for #1 I don't have my own threads, so I was thinking only in single-thread context, where I understood them to be synchronous, as you confirm. That also applies to the OP's example.

            I do have one question about your code & explanation. Please bear in mind that I only use Qt from Python, I don't have the C++ code or macros to look through to discover this for myself. With that in mind, I want to understand the root of the distinction between your cases #1 & #2.

            You are saying "emit <signal> behaviour varies depending on sender/receiver being in same or different threads". Now, I believe I am correct in saying that in your C++ emit is a macro which expands to nothing at all. In which case in both cases the code simply expands to the function call in the source immediately after the emit. Since emit in itself does nothing at all in the code, how do you get that behavioural difference you describe? It's just a C function call, so it knows nothing about same or different threads?

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

            @JonB said in Signal/Slot process order in function:

            how do you get that behavioural difference you describe?

            That's the magic of moc. It gives a body to your signals that basically is an if to check the threads and if they are the same it calls the slots otherwise saves the argument and schedules an event to trigger the slots as soon as the event loop takes control

            "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

            JonBJ S 2 Replies Last reply
            2
            • VRoninV VRonin

              @JonB said in Signal/Slot process order in function:

              how do you get that behavioural difference you describe?

              That's the magic of moc. It gives a body to your signals that basically is an if to check the threads and if they are the same it calls the slots otherwise saves the argument and schedules an event to trigger the slots as soon as the event loop takes control

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by JonB
              #6

              @VRonin
              Ah ha! And what is/am I using moc if I am Python/PyQt?? :)

              1 Reply Last reply
              0
              • VRoninV VRonin

                @JonB said in Signal/Slot process order in function:

                how do you get that behavioural difference you describe?

                That's the magic of moc. It gives a body to your signals that basically is an if to check the threads and if they are the same it calls the slots otherwise saves the argument and schedules an event to trigger the slots as soon as the event loop takes control

                S Offline
                S Offline
                samdol
                wrote on last edited by
                #7

                @VRonin
                Thank you. It is quite clear to understand.

                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