Let's say I have a signal change connected to a slot notify. If the change signal is emitted, the notify slot will start executing.
Now what happens if a second change signal is emitted and the first notify slot didn't finish its execution?
Is the second slot launched concurrently with the first? And if so, is Qt handling the thread-safety or it's up to the programmer to handle it?
It is not thread safe, you cannot enqueue and dequeue concurrently from different thread.
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.
The Qt signals/slots and property system are based on the ability to introspect the objects at runtime. Introspection means being able to list the methods and properties of an object and have all kinds of information about them such as the type of their arguments.
It depends on connection type you specified via calling connect
function. The only way when slot will be launched concurrently is if you specified Qt::DirectConnection
AND emitting signal in thread different from slot's thread. If you omit connection type, it would be Qt::AutoConnection
. In this case if you emit a signal from one thread, and catching it in another one (e.g. in main GUI thread) - Qt will put a slot's call to the message queue and will make all calls sequentially. Read this for further info - http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads
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