Qt:: Talking about the signal slot connection, the use of parameters in multi-threading

The Qt signal slot has five connection methods defined in the enum Qt::connectiontype, below a brief introduction

Qt::autoconnection: Automatically determine the connection mode, if the signal sending object and execution slot object on the same thread, then equal to QT::D irectconnection, if not equal to Qt::queuedconnection

Qt::D irectconnection: Direct connection, simply called direct, signal sending will be returned after the slot function is completed, but only if the signal and slot objects must be in the same thread, otherwise an unknown error will occur

Qt::queuedconnection: Queue connection mode, signal sending is to notify the current thread event mechanism to add a pending event, the execution of the slot does not necessarily return immediately, send the signal to return immediately, the two are executed asynchronously, mainly to solve the signal and the slot object does not block the same thread

Qt::blockingqueuedconnection: Blocking queue connection mode, the logic is the same as the first, the only difference is that the signal will not be returned immediately, will wait until the slot execution is returned, only return the signal call, for the need to block wait until the return value results, you can use

Qt::uniqueconnection: Independent connection method, this logo is less used, and the above 4 identification can be done or operation to indicate that the connection object is a singleton, if there is the same object signal bound to the same slot, the binding action will return the failure

Single-threaded situation there is nothing to say, the second way of direct invocation, mainly on the multi-threaded situation

The user who writes the UI should have used the following callback function because the QT lining thread cannot manipulate UI-related object interfaces and must pass events and actions to the main thread processing

Then generally there will be two cases, blocking and non-blocking, blocking is the need to wait until the return value of this action can be executed, if the third connection, even if the addition of qgenericreturnargument is not valid, you need to choose the fourth type of connection

But Qt::blockingqueuedconnection is prone to deadlocks when a child thread is not under your control or in your own code, such as a method that invokes a thread on the main thread, and in this method sends a signal to the main thread to handle the event. Since the child thread has been waiting for the main thread to finish processing the event returned to continue down, but the main thread is stuck in the call to the sub-threading method, resulting in the two direct deadlock, so this connection should be used with caution, at least you have to understand the connection to trigger a series of call relationships to confirm how to handle; , that is the case of the pointer in the parameter, if the pointer to the object is a temporary variable, when the non-blocking way to hand over the time, the object may have been the destruction of the recovery, then the call parameter will access a wild pointer, so either copy a pointer data to a reliable place (at least to confirm that the data is still in progress) You can either use blocking, wait for processing to finish, and then release the pointer to the object.

Demo code to be continued, the main will be listed in several ways of normal call notation

Qt:: Talking about the signal slot connection, the use of parameters in multi-threading