Understanding signal slots in Qt


We use the signal and slot mechanism in too many places in Qt to implement our functions, but have we carefully considered the principle of the signal and slot mechanism? Have you ever asked yourself the following questions:

  • Is the signal slot synchronous or asynchronous, blocking or non-blocking?
  • How are signals and slots implemented or based on what they are implemented on?

This article is a view to answer the above questions. Okay, let’s get into the whole thing. First, let’s introduce how to use signal slots. Everyone knows this, but we still have to start from the beginning. To use signal slots, you need to use the connect method. The declaration of this method is as follows:

[static] QMetaObject::Connection QObject::connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type = Qt::AutoConnection)

The introduction of each parameter in the above statement is as follows:

sender: represents the pointer of the sender object, the type is QObject*

signal: represents the signal sent by the sender, the type is const char*

receiver: represents the pointer of the receiver object, the type is also QObject*

method: represents the slot function name of the receiver, the type is const char*

AutoConnection: represents the connection type. This is an enumeration type. The type is Qt::ConnectionType. The enumeration values ​​are as follows:

  • Qt::AutoConnection: This value is the default value. If the value of AutoConnection is not specified when calling the connect method, this value will be used as the default value. The meaning of this value is that if the thread sending the signal and the thread receiving the object are the same thread, then AutoConnection=Qt::DirectConnection; otherwise AutoConnection=Qt::QueuedConnection. Note that the emphasis here is on which thread the object is sent, not which process the object is created in. Don’t get confused here. To make it clearer, even if the launching object and the receiving object are in the same thread, the signal is sent in another thread. Will AutoConnection=Qt::QueuedConnection.
  • Qt::DirectConnection: The meaning of this value is that the slot function will be called directly in the signal sending thread, that is, the slot function will be executed in the signal sending thread. Obviously this is a synchronous call .
  • Qt::QueuedConnection: Queue connection. The result of this connection method is that the slot function is executed in the thread where the recipient object is located. This is different from the DirectConnection connection method. And this connection method is completed by triggering an event loop, that is, using this method, the event is ultimately sent to the event queue of the thread where the receiver object is located through the postEvent method, and then the slot function call is implemented through the event queue loop. From here It can be seen that this is an asynchronous call .
  • Qt::BlockingQueuedConnection: The function of this connection method is basically the same as that of QueuedConnection, except that after the signal is sent, the signal sending thread will block in the signaling statement until the thread slot function where the receiver object is located is executed and returned. Will continue to execute. However, it should be noted that if this method is used, the signal sending thread cannot be in the same thread as the thread where the receiver object is located, otherwise it will cause the program to deadlock. I have a question here, which is how to return the slot function execution result to the signal sending thread using this connection method. (It should still be emphasized here that the thread where the signal sending object is located and the signal sending thread may be different, and the two cannot be simply equal). So far it can be seen that this connection method is also an asynchronous call .
  • Qt::UniqueConnection: This connection method cannot be used alone. It must be used in combination with the above connection methods. Its meaning is to ensure that the same sender object, the same signal, the same receiver object, and the same slot function only It can be bound once, otherwise calling the connect method will fail.

Guess you like

Origin blog.csdn.net/iqanchao/article/details/132790959