Main thread - worker thread communication.

[wysota]

If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.

[kikapu]

If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.

Ok, i see...very helpfull post indeed. The "queued connections", as i saw it, are a very nice way to keep things simple and not complicated. regarding the Singals and Slots mechanism and the communication over different threads. (In fact, i like it even more that the respective C# stuff)
Is there any "catch" with that ? Performance problems or something else ?

[wysota]

They are a bit slower as you have to serialise all the arguments and then recreate them back in the other thread when the slot is executed. And there is of course the latency between emiting the signal and the other thread processing it. Oh... and the other thread has to have an event loop running of course.