Possible QThread Process Problems

First, let's talk about the background of the story. When we click a button or something like a control, we may want it to perform complicated operations, however, we do not want the program to be stuck there and wait for the execution of this complex operation to end. multithreading is required here. Although I still don't know how to use multithreading in QT, however, let's make it a summary for future reference.

It is said that it is a good method to implement multithreading on many websites! Also give a related link:

Bytes.

QThread pingThread;QObject::connect(&obj, SIGNAL(sig()), this, SLOT(getData()), Qt::QueuedConnection);Dummy dummy;obj.moveToThread(&pingThread);QObject::connect(&dummy, SIGNAL(sig()), &obj, SLOT(pingIp()), Qt::QueuedConnection);pingThread.start();dummy.emitsig();

Except for the second line of code, the code is copied from the original one. It should be noted that this program is not in main, so there is no message loop, in addition, the obj here is a member of the current class. As for the reason why the pingThread here is a sub-thread, we will move the obj to this thread, that is, the class where obj is located is the sub-thread. The slot pingIp in the sixth line is defined by ourselves. The specific implementation is not the code here. In short, it is a series of very time-consuming operations. After the operation is complete, we need to return the operation result. How can this be done? SLOT does not return the value, nor does it return the value? This is a useful member of this obj, in the SLOT, the result must exist in the member variable of obj, which must be global. Otherwise, it cannot be taken out.

Next we will talk about this key second line. Here a connection is established. The sender of the signal is obj, and the receiver is the current class, therefore, a signal sig must be sent at the end of the pingIp slot of the obj class. Here, the header file of the obj class is provided to illustrate the situation.

#include <QObject>class Object: public QObject{    Q_OBJECTpublic:    Object();    std::vector<QString> m_linkVec;    std::vector<int> m_succeedVec;    std::vector<QString> m_ipVec;signals:    void sig();public slots:    void pingIp();private:                                                                                                                                                                                                                                                                                                                                                                                                                                                                      };

The vectors defined here are the results to be returned after the final processing. sig () is the signal to be sent by obj. This signal must be sent in the last line before the pingIp ends, then this signal will be connected to the slot we created in the second line, and the required results will be retrieved back to the main thread through the getData () slot.

There will be a problem here, that is, when the sub-thread is still being executed, the main thread may have ended. This is completely impossible, so we need to consider the object's survival, because the sub-thread is still executing and the main thread has ended, it is bound to define temporary variables in the main thread, such as the pingThread in the first line. This release will directly cause the program to crash, because all the thread objects are lost, how can we execute the thread? The program must have been running? So before the child process ends, the pingThread cannot be parsed or released, the reason why the code of those people on the internet is okay is that they are all tested in the main function. Of course, the main function will end after you close it, or the message loop will continue, so the program will not run and I is different from ours. We do it in the member functions of the class and it is normal to finish the execution, so we should keep this pingThread after the execution is finished, to prevent program errors caused by incomplete sub-processes, you need to set the pingThread as a class member and obj as a member because the data needs to be retrieved for different purposes.

In conclusion, the signal slot mechanism is used to connect signals and slots between different threads. Therefore, we usually need to set the fifth parameter "message transmission mode" of the signal slot, which is not frequently used. Here we will briefly describe this parameter.

Qt::AutoConnectionQt::DirectConnectionQt::QueuedConnectionQt::BlockingQueuedConnectionQt::UniqueConnectionQt::AutoCompatConnection

There are a total of six methods, the first two are similar, are connected between the same thread, the difference is that Qt: AutoConnection is the default connection method of the system, in this connection, the slot is not executed immediately, but enters a message queue. When it is executed, it is not known to the programmer. The second is a direct connection, that is, as long as the signal is sent directly to the slot for execution, it is a relatively brainless method. The third and fourth types are similar and can be connected between different processes. The difference is that the third type is executed in the current thread of the object, it is executed in the queue order. When the current thread stops, it will wait for the next thread to start and then run in the queue order, waiting for QApplication: exec () or QThread: exec () of the thread () to execute the corresponding slot. The fourth type is that the signal must be different from that of CaO in different threads; otherwise, a deadlock will be generated directly. This means that the full synchronization queue will return only after the slot thread completes execution, otherwise, the sending thread will wait, which means different threads can be synchronized for execution. The fifth method is the same as the default method, but the same signal and slot cannot be connected repeatedly, the sixth method is to connect the signal slot mechanism from QT4 to QT3 in the same way as Qt: AutoConnection. Obviously, we should select the third method. We don't want the sub-thread to wait until it ends. We just want to use this idle time to do other things. When the sub-thread is finished, you only need to send the message to the main thread, and then the main thread will respond.

This article from the "selling cute programmers" blog, please be sure to keep this source http://7677869.blog.51cto.com/7667869/1288018