Does emit make a difference for slots with different thread affinity?

SiGa

I read at multiple sources that emit is a macro for syntax sugar and you could call the signal directly instead of using emit.
However, in the referenced blog post, @SGaist referenced the documentation(https://doc.qt.io/qt-5/signalsandslots.html), which states:

When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. Execution of the code following the emit statement will occur once all slots have returned. The situation is slightly different when using queued connections; in such a case, the code following the emit keyword will continue immediately, and the slots will be executed later.

For clarification, so it makes a difference when you are using different threads?

JonB

@SiGa
emit (or Q_EMIT), as I wrote there, is nothing but a #define to empty, it's just to help you notice it's a signal. Recommended but not significant. So forget anything about the keyword emit itself. emit someSignal() expands to just someSignal().

The function that is called is the signal. The way that causes slots to be called differs (unless you do something explicit in the connect() statement) depending on whether the signal-slot connection is same-thread or cross-thread (at runtime): slot called directly in former case, slot queued for other thread's event loop in latter case. Hence same-thread/direct-connection signals make caller wait till all slots executed, cross-thread/queued-connection have caller continue immediately after simply posting the call to a queue for later execution.