QT signals and slots direct connection behaviour in application with a single thread

Question

I am having difficulty grasping what happens when for eg. two different signals are connected to two different slots and when one slot is not done, the other slots' signal is emitted (for both slots connected to their respective signals in a direct connection) where the application only has "one" thread.

This is from the QT official documentation:

Direct Connection: The slot is invoked immediately, when the signal is emitted. The slot is executed in the emitter's thread, which is not necessarily the receiver's thread.

Queued Connection: The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.

It says "immediately" for direct connection unlike the queued connection. Does that mean, if the second signal is emitted when the first slot is not done yet, the first slot will be interrupted and it will run concurrently with the second slot even though the application is a single threaded application? If so, why don't I see any warnings that one should use mutexes to lock variables that could be accessed by both slots.

Maybe I am misunderstanding the whole "Direct" and "Queued" connection thing.

Answer 1

I think you are misunderstanding not the queued and direct versions, but the whole signal/slot mechanism as a whole. The signal/slot system is a more elegant solution to the callback problem, when you synchronously or asynchronously need to know when another part of your application (this may be single or multi-threaded) is done doing its work.

Direct / Queued

Let´s get this out of the way before diving into the basics.

• If it is a direct connection, your code is ALWAYS executed on a single thread, regardless as to whether or not the slot is running on a different thread. (In most cases a VERY BAD idea)
• If the connection is queued and the slot is running inside the same thread, it acts exactly like a direct connection. If the slot is running on a different thread, the slot will execute within its proper thread context that it is running in, so making the code execution multi-threaded.
• If the connection is auto which is the default, for a good reason, then it will chose the appropriate connection type.

Now there is a way to force your code execution to jump into a slot in another thread, that is by invoking a method:

QMetaObject::invokeMethod( pointerToObject*, "functionName", Qt::QueuedConnection);

The Basics

So let´s go over the signal/slot mechanism quickly. There are three actors in the system : signals, slots and connect()

Signals are basically messages that say "Hey! I am finished". Slots are places in your code where post-processing happens, so once the signals are finished you can do something in the slot part of your code.

connect() is the way to organise what happens where and for what reason. The order of execution for signals/slots is the same as your code execution order. First come first serve, since you did mention single-threaded. In a multi-threaded environment that´s different. Honestly the order of execution shouldn´t matter, if you are trying to work with signals/slots and need a guaranteed order of execution you are designing your application wrong. Ideally you use the signal/slot mechanism in the same way that functional programming works, you pass messages along to the next instance to work on the data.

Enough ranting, let´s go down to some practical specifics:

signals:
    void a();
    void b();
slots:
    void sa();
    void sb();

Case 1

connect( a -> sa );  // Simplified Notation. Connect signal a to slot sa
connect( b -> sb );

:: emit a(); -> sa is executed
:: emit b(); -> sb is executed

Case 2

connect ( a -> sa );
connect ( a -> sb );
connect ( b -> sb );

:: emit a(); -> sa & sb are executed
:: emit b(); -> sb is executed

---

I think this should make it clear. If you have anymore questions let me know

Answer 2

Direct connection means that emitting the signal and calling the slot are shortcutted to a simple method call, making the emit call jump directly into the slot. Queued connection puts the call into a queue, which is handled as soon as the Qt event loop is running again, or you force it by calling QCoreApplication::processEvents(), in line with all other events that have been queued until then.

In a single threaded application (more exactly: when sender and receiver object live in the same thread), direct connection is the default except you state otherwise when calling QObject::connect(). This implies that during execution of a slot or other code any emit in this code calls the connected slot immediately - which can be what you intended, or sometimes not.

You didn't say what, if any, actual problems you have with your signals, but be aware of eternal loops, deadlocks and other locking/mutex issues; mutexes shouldn't be necessary at all in single threaded code. Keep the signal/slot call chains as simple as possible and avoid emit within slots if ever possible.

Answer 3

A direct connection is exactly like a call through a function (method) pointer. There is no "interruption", unless you think that in the code below printf() "interrupts" main():

// main.cpp
#include <cstdio>
int main() {
  printf("Hello\n");
}

All of the code runs in the same thread. The main() and printf() never run concurrently: while printf() runs, main() is suspended. Once printf() returns, main() resumes. The same happens with slots/functors directly connected to signals.

For example, let's have the following Object, and a Monitor class to visualize what's going on.

// https://github.com/KubaO/stackoverflown/tree/master/questions/sigslot-nest-38376840
#include <QtCore>
struct Monitor {
   int & depth() { static int depth = 0; return depth; }
   const char * const msg;
   Monitor(const char * msg) : msg{msg} {
      qDebug().noquote().nospace() << QString(depth()++, ' ') << msg << " entered";
   }
   ~Monitor() {
      qDebug().noquote().nospace() << QString(--depth(), ' ') << msg << " left";
   }
};
struct Object : QObject {
   Q_SIGNAL void signal1();
   Q_SIGNAL void signal2();
   Q_SLOT void slot1() { Monitor mon{__FUNCTION__}; }
   Q_SLOT void slot2() { Monitor mon{__FUNCTION__}; }
   Q_SLOT void slot3() {
      Monitor mon{__FUNCTION__};
      emit signal2();
   }
   Q_OBJECT
};

Let's have signal1 connected directly to slots slot1, slot2 and slot3. Further, let's have signal2 connected directly to slots slot1 and slot2:

int main() {
   Monitor mon{__FUNCTION__};
   Object obj;
   QObject::connect(&obj, &Object::signal1, &obj, &Object::slot1);
   QObject::connect(&obj, &Object::signal1, &obj, &Object::slot2);
   QObject::connect(&obj, &Object::signal1, &obj, &Object::slot3);
   QObject::connect(&obj, &Object::signal2, &obj, &Object::slot1);
   QObject::connect(&obj, &Object::signal2, &obj, &Object::slot2);
   emit obj.signal1();
}
#include "main.moc"

The output makes it clear that any slots directly connected to signals that you emit are executed while the signal is running. Additionally, no event loop is necessary for the directly connected slots/functors to work. Finally, remember that a signal is "just" a moc-generated method that invokes all the directly-connected slots/functors.

main entered
 slot1 entered
 slot1 left
 slot2 entered
 slot2 left
 slot3 entered
  slot1 entered
  slot1 left
  slot2 entered
  slot2 left
 slot3 left
main left