Newbie threading question

[marcel]

No, it's 4.2.2.

EDIT - with the code from the first post...
Wasn't the event posted when the signal was emitted? What you see in the call stack is the posted event being processed.

[wysota]

Oh, I see what's wrong You're calling a slot from the thread and not an object created in the thread. The QThread instance lives in the thread that created the object (the main thread in this case). So when you call a slot from the QThread object, it is executed in the context of the main thread and not of the worker thread. Either move the slot to an object created in the run() method of your thread or change the thread affinity of the QThread object using moveToThread(). Just make sure to do it after the thread is actually started.

[wysota]

Here is a small example to demonstrate what I mean.

[marcel]

I think you complicated things a bit there... It works by calling myThread->moveToThread(myThread) right after starting the thread, in the main window constructor.
A good idea nevertheless....

Regards

[wysota]

I didn't complicate anything. It was just an example to show that the affinity changes and the connection type changes from Direct to Queued.

[marcel]

It was all about moving the event processing for the thread to the thread event handler...
It can be seen now on the call stack that the event is treated in MyThread::exec() not QApplication::exec(), as before.

[wysota]

That's exactly what a "queued" connection means.

[marcel]

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

[wysota]

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.

[marcel]

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.

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.