That's exactly what a "queued" connection means.
That's exactly what a "queued" connection means.
Yes, I know. It was queued before, but it was treated in the GUI event handler, not in the thread's event handler. That is why it blocked the interface.
Regards
No, it wasn't queued. If you don't pass a connection type to connect() (like it is the case here) it defaults to Qt::AutoConnection, which means that when a signal is emitted and Qt iterates slots that are connected, it checks if the caller and callee live in the same thread. If so, it calls the slot directly (like in this situation). Otherwise it posts an event to the receiving thread.
BTW. I'm not sure it is reliable to change the thread affinity immediately after calling QThread::start(). The thread may not be started at that point yet. It's safer to move the object on the QThread::started() signal.
True.
Also, in the Assistant, there is stated:
With auto connections (the default), the behavior is the same as with direct connections if the signal is emitted in the thread where the receiver lives; otherwise, the behavior is that of a queued connection.True.I'm not sure it is reliable to change the thread affinity immediately after calling QThread::start(). The thread may not be started at that point yet. It's safer to move the object on the QThread::started() signal.
Bookmarks