Traditional graphical interface applications have only one thread to execute and one operation at a time. If the user invokes a more time-consuming operation, the interface response is frozen.
One solution is to follow the event-handling approach:
call void Qapplication::p rocessevents () or void Qapplication::p rocessevents (int maxtime) to force an event loop, but this approach is potentially risky. According to Qcoreapplication:processevents (), it is possible to cause recursion, resulting in a stack overflow crash, when the main thread is executing processevents in a slot function, There is just one signal that responds to this slot function (which is definitely a signal from another line Cheng), and a terrible recursion can occur, causing the stack overflow to crash. The reason is that processevents, when dealing with the event of its own slot function, calls to processevents and goes into endless recursion.
Another solution is to use multithreading. 、
QT Qthread multithreaded Programming method has been a controversy, that is Bradley T. Hughes:you ' re doing it wrong inductive to 3 method pros and Cons:
Method (1):
1. do not use event loops . This is one of the official Manual, example and related books that are described in this way.
A. Sub-class Qthread
B. Overloading the run function with a dead loop for a while or for in the run function
C. Set an exit that is marked to control the dead loop.
The run function here performs a loop by itself and does not require an event loop mechanism.
Method (2):
This approach is also Bradley T. Hughes's critical critique of a. Subclass Qthread, B. Overload run to call Qthread::exec () C. and define signals and slots for the class, so that because the slot function does not run on the newly opened thread, many humans To resolve this problem in the constructor call Movetothread (this);
Controversy and confusion are the result of such a statement.
Bradley T. Hughes gives the explanation that Qthread should be considered an interface or control point for an operating system thread, and should not contain code that needs to run in a new thread. The code that needs to be run should be placed in a qobject subclass and then movetothread the object of that subclass into the new thread.
Method (3):
Before Qt4.3 (including), run is a virtual function, you must subclass Qthread to implement the run function. Starting with Qt4.4,qthreads-no-longer-abstract , run, calls Qthread::exec () by default. This does not require a subclass of Qthread, only the subclass of a qobject is enough, this is the method recommended by Bradley T. Hughes.
Methods are as follows
Qthread thread; Object obj; Dummy Dummy; Obj.movetothread (&thread); Qobject::connect (&dummy, SIGNAL (Sig ()), &obj, slot (slot ())); Thread.Start ();
So, method (1) and Method (3) is the correct QT Qthread multithreaded Programming method, Method (2) with the most, but only all men say, an inappropriate usage
Qthread multithreaded Programming Classic case study