*[SOLVED]* Multiple signals and single slot...



  • Hello,
    I have written a code in which a slot is connected to multiple signals of different threads.
    Now there is a possibility of simultaneous emission of signals.

    So what I am thinking is, since the connection type is Qt::AutoConnection and senders and receiver are in different threads, signals emitted will be delivered one by one to the receiver's event loop, i.e. after the execution of slot is completed for a signal... hence the action against the signal will not be parallel...
    Am I right.??



  • Yes. The cross-thread signals will go via the event loop. Events are put on the event queue of the eventloop for the thread of the receiving object. That queue is protected by a mutex (I think, it might be some other synchronization mechanism, I did not check the sources). That means that signal invokations will become serialized.



  • That means that signal invokations will become serialized.

    does this mean that the execution of pending signals will be done only after the execution of current slot is completed.??
    what happens in case where the slot is waiting for something (wait state) or goes into sleep for sometime (sleep or msleep) [ideally it should not be like this, asking just for knowledge], will the execution of next signal will be carried out, in parallel??

    The thing I am concerned about is protection of a resource which is being operated from the slot [single] upon emission of signal [multiple].



  • Yes, in a single thread, the execution is only at a single point of your code. That includes handling signals... If you suspend that thread, the whole thread is suspended.



  • ok... i wrote a sample code for this.

    and what i understood is, in case of simultaneous emission of signals (connected to single slot), the execution of the slot will be non-blocking (i.e. signals will be queued up to be executed later, if slot is already serving any signal and emitter thread will continue execution) and slot will respond to the signals, one by one, as per their order in event queue.

    Am I right.??
    I found the same behavior in case where the SIGNAL is in C++ and SLOT is in Qml. [also checked with sample code]



  • Not sure what you mean here. Simultaneous emission of signals can only be across threads. Within a single thread, that is impossible. Across thread signals are by default indeed non-blocking: the emitting thread just continues work, the receiving one will pick off the corresponding event from the queue when there is time for it, and process them one by one.



  • Yes, I do mean the different thread... this is rough outline of the program I tested.

    @
    class SignalThread : public QThread
    {
    public:
    SignalThread ()
    {
    }

     void run ()
     {
          while (1)
          {
               emit someSignal ();     // emits signal
               msleep (1);               // for context switching
          }
     }
    

    signals:
    void someSignal ();
    }

    class SlotClass
    {
    public:
    SlotClass ()
    {
    for (int index = 0; index < MAX_SIGNALS; ++ index)
    {
    connect (&signalThread [index], SIGNAL (someSignal ()), this, SLOT (someSlot ()));
    signalThread [index].start ();
    }
    }
    private:
    SignalThread signalThread [MAX_SIGNALS];
    public slots:
    void someSlot ()
    {
    qDebug () << "signal received";
    }
    }
    @

    with event loop running in main function, i.e. a.exec ();

    thanks for the guidance, it is helping me.



  • sorry, I forgot to mention...
    I had taken multiple instances of signal class, which emits signals in while loop, to obtain simultaneous emission.



  • I guess you're just blogging on what you're doing now? Or do you have a question on all that?



  • yes, just updated the code for sake of clarity.
    My question is solved. thanks. :)


  • Moderators

    Be sure and edit the thread title to add [Solved]. Thanks!


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.