Menu
I am not sure about the nature of the signal/slot mechanism in Qt 4.5. When a signal is emitted, is it a blocking function call or a thread? Say this
emit GrabLatestData(); // proceed with latest data Will all the signal/slot chain be resolved before proceeding to the next line?
269
In Qt, we have an alternative to the callback technique: We use signals and slots. A signal is emitted when a particular event occurs. Qt's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them. A slot is a function that is called in response to a particular signal.
So in normal cases, it will be synchronous and blocking, and with queued connections it will be asynchronous and non-blocking.
It is generally unsafe to provide slots in your QThread subclass, unless you protect the member variables with a mutex. On the other hand, you can safely emit signals from your QThread::run() implementation, because signal emission is thread-safe.
It depends. From the documentation:
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
emitstatement 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.
So in normal cases, it will be synchronous and blocking, and with queued connections it will be asynchronous and non-blocking.
177
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
