Qt, direct connection and queued connection difference

dctcln

It is said in this post (https://stackoverflow.com/questions/38376840/qt-signals-and-slots-direct-connection-behaviour-in-application-with-a-single-th) that:
- 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.

According to this statement, when in same thread, queued connection acts exactly like a direction connection, that will then be identical to a simple function call, which means the emission will not return until the queued slot finished execution?

I do not feel this right, anyone can help to clarify?

rolandash

NO it does not seems right.

Check out the source code here in this link: https://woboq.com/blog/how-qt-signals-slots-work.html

        // determine if this connection should be sent immediately or
        // put into the event queue
        if ((c->connectionType == Qt::AutoConnection && !receiverInSameThread)
            || (c->connectionType == Qt::QueuedConnection)) {
            /* Will basically copy the argument and post an event */
            queued_activate(sender, signal_index, c, argv);
            continue;
        } else if (c->connectionType == Qt::BlockingQueuedConnection) {
            /* ... Skipped ... */
            continue;
        }

It is then very clear that queued connection will post the event into thread queue, no matter in or not in the same thread, rather than initiate a simple function call.