PDA

View Full Version : QThread deleteLater()



doggrant
10th February 2012, 11:39
Hi,

I've got an issue where I'm trying to use deleteLater() to delete a thread after it has finished running. Therefore I have:


void MyThread::run()
{
//MyThread Work done here

deleteLater();
}
However, since MyThread has no parent, the deletion of the thread seems to only occur when the applciation exits. Does anyone know how this can be changed?

David

wysota
10th February 2012, 12:09
deleteLater() has nothing to do with parentship. You just need a running event loop in the thread owning the object you wish to delete (in your case the QThread instance).

However such an unconditional self-deletion is dangerous since you don't know whether the object has been allocated on heap or on stack. The object should never delete itself. It is much better to connect the finished() signal to the deleteLater() slot from outside of the object.

doggrant
10th February 2012, 13:49
Can any qobject have an eventloop?

I have a qobject that is a storage class called 'Card'. Because some of the cleardown routines for this class take time to complete, I run them in a thread that is a member of that Card object.

Therefore once that thread has completed, i want the qthread itself to be destroyed.

I also tried:

connect( m_pCloseComponentsThread, SIGNAL( finished() ), m_pCloseComponentsThread, SLOT( deleteLater() ), Qt::DirectConnection );

Just after creating the thread, but this still fails to call the qthread destructor until my app exits.

Any ideas?

wysota
10th February 2012, 15:39
Can any qobject have an eventloop?
Objects don't have event loop. Threads do.


Because some of the cleardown routines for this class take time to complete, I run them in a thread that is a member of that Card object.
That's probably not a very good idea.


Just after creating the thread, but this still fails to call the qthread destructor until my app exits.
Do you have an event loop running?

doggrant
10th February 2012, 16:05
Because some of the cleardown routines for this class take time to complete, I run them in a thread that is a member of that Card object.


That's probably not a very good idea.

I know this might not be the best idea, but since i have no control over the external library, which is slow, I need to use a thread to call the external routines.

What I have is the following:

QMainWindow, which has an event loop (Have called exec() is here)

|
|_ _ _ Hotswap QThread that uses waitformultiple objects to wait for events from an external library.
Exec() not called here, since my own thread processing is in run()


|
|_ _ _ When an event fires in the hotswap thread, a card object is created, and
after getting info about the card, the cleanup thread is run.
Note: The card object will still be alive after the cleanup thread has been executed.


So what I really need is a way to call delete on the cleanup thread, when the finished() signal fires, but i'm not sure how to do this in this instance.

wysota
10th February 2012, 16:32
I know this might not be the best idea, but since i have no control over the external library, which is slow, I need to use a thread to call the external routines.
No, you don't. Unless you want to crash your app sooner or later but there are easier ways to do this than allowing multiple threads to access the same data.


So what I really need is a way to call delete on the cleanup thread, when the finished() signal fires, but i'm not sure how to do this in this instance.
Make the QThread object controlling the cleanup thread live in the main thread so that its slot gets executed.

doggrant
16th March 2012, 16:51
Hi,

when looking at the stack there was nothing there, the thread had exited, unless i should have been looking at the stacks of other threads involved.

On a good(ish) note, i tried the same application today, and the problem does not occur when debugging. I beleive it may be a timing issue when debugging, but will not be able to look at it again unless it re-occurs!

David

amleto
17th March 2012, 17:21
The QThread should be on the main thread anyway - you're not moving it anywhere, are you?