Home > Mobile >  Arguing about QTimer and thread a wonderful work, don't know how to solve
Arguing about QTimer and thread a wonderful work, don't know how to solve

Time:11-20

If there are 2 people, 1 personal writing Qobject class, a person to write the main thread UI, well, I'm the first person to encapsulate a Obj, his constructor like this:
 
ClassA: : ClassA (QObject * parent) : QObject (parent)
{
Ti=new QTimer (this);
Ti - & gt; SetInterval (1000);
The connect (ti, SIGNAL (timeout ()), and this, SLOT (onTimeut ()));
Ti - & gt; Start ().
}

He felt my own timer is timing trigger I a slot function, and the timer is mine, so the timer parent to himself, that he had been destructor, timer and destructor will together, destructors are too lazy to write, no problem,

Another person to write the main thread:
 
A=new ClassA ClassA * ();
QThread * th=new QThread ();
A - & gt; MovetoThread (th);
Th - & gt; Start ().

This don't know what to achieve in this Class A, he also don't need to know, need only in accordance with the rules of grammar new A, then delete behind A right, but that the delete, QTimer is an error, QObject: : killTimer: timers always be stopped from another thread,
Oh by the way, if you think you will give the child thread, and write the main thread should be, that is a shame, you write the same error so,
 
Th - & gt; quit();
Th - & gt; Wait ();
Th - & gt; Deletelater ();
Delete a;


So could you please tell me: both feel reasonable, no problem, who is the problem? What is the general method or idea to avoid this problem,

CodePudding user response:

after repeated tests, I found this was the only solution? Must to signal channel, not manually quit wait the delete, mainly a few key points:
For ClassA this class, is the key to construct the new QTimer is a parent specifies ClassA, so when others leave ClassA moved to the new thread, the timer will follow together into the new thread, then when the delete, delete the thread of execution, no signal channel, the probability is in the main thread to delete, so this time, the timer - & gt; Thread () and currentThread (), it is not the same thread that would be an error, if the first traverse to the child thread quit wait delete drop, then the timer and ClassA thread () is NULL, the same error,
So can't after deleting the child thread, towed ClassA and then back to the main thread? Unfortunately, QT documentation indicating that moveToThread can only put the Obj "out", not "back", so can't thread to a set of the quit () wait deletelater () (), and then ClassA - & gt; Deletelater (), also not line, because ClassA thread () is already empty, deletelater is actually postEvent, i.e. ClassA won't deal with this event, you can have a try, the destructor will not be invoked, and this is a disaster,

CodePudding user response:

To summarize:
1. The other in the Obj Obj, including QTimer, specifies the parent this for themselves, others outside moveToThread will put your timer thread also move in the past,
2. If other people outside the delete your Obj, then your Timer destructor call stop (), when judging inside thread ()!=QThread: : currentThread () is set up, and then quote us warning qWarring,
3. Deletelater postEvent, namely destructor will be in the groove function, which is in the child thread, this may be the only solution, after all your destructor of the timer stop () the child thread on dry,
4. MoveToThread can push the Obj to the child thread, can't back to the main thread,
5. That is to say, the stop time of the timer, timer thread () to be intact and cannot be deleted, and then execute the stop () the thread, can't be other threads, so will signal trough kill two birds with one stone, the th - & gt; In wait () this function will wait, then I will send a signal, then the timer! Ta will be destructor in the child thread off, and then thread destructor myself away,

CodePudding user response:

Don't use QTimer in timerEvent won't appear this kind of circumstance

CodePudding user response:

reference mango black reply: 3/f
without QTimer in timerEvent won't appear this kind of circumstance!!
this you can have a try, but not in my discussion of scope, I talk about my normal use a thing, I only know the rules of qt and c + +, what other co-workers, netizens "custom rules" between all don't know, but I must under the rules of the only two, are not allowed to go wrong, that is to say, who are not allowed to make special, if there is something special, that is serious damage rules of encapsulation and design patterns, why have to make special use timerEvent, can I use the timer

CodePudding user response:

If must say who problem, must be the first person's question, he doesn't take into account this class will be loaded into another thread running, so new and delete is not in the same thread

CodePudding user response:

I think moveToThread () this way good trouble, but also the connection of started, signals and slots function than inheritance QThread alone more than one thing good

CodePudding user response:

5/f, different threads, obj cannot delete each other directly, only through signal channel to achieve the delete across threads

CodePudding user response:

refer to 7th floor water cave reply:
5 floor, different threads, obj cannot delete each other directly, only through a signal channel to achieve across threads delete
HMM? In other words, if a obj through a move to move to the child thread, it is necessary to use signal channel to delete?

CodePudding user response:

refer to 7th floor water cave reply:
5 floor, different threads, obj cannot delete each other directly, only through a signal channel to achieve across threads delete
that is only a signal - & gt; The obj deletelater (), like this? But there's a problem, is not complete, if the obj thread that was out of the, then the obj is not performing events, namely groove function does not perform
  •  Tags:  
  • Qt
  • Related