Using a QThread without new

1
votes

So I have some sample code below.

workerThread = new QThread();
m_worker->moveToThread( workerThread );
connect( workerThread , SIGNAL( started() ), m_worker, SLOT( createObject() ) );
connect( m_worker, SIGNAL( created() ), this, SLOT( objectReceived() ) );
workerThread->start();

It currently uses a QThread by initializing it with new. If this is the only context it is used in, couldn't I just use "QThread workerThread", reference its address for connection, and be done? This would save the program from putting the thread on the heap. I noticed if I don't use new and use the way I listed, I get the following error "QThread: Destroyed while thread is still running". Nothing changed in the code except the changes I listed. If I use new I do not get this error. Is there a significant difference?

2
c++qtqthread
Does the function that contains this code return before the thread terminates? – Martin James
Obviously you could do that, it is just not ideal in many user case. If you don't want control over the thread lifetime then use stack allocation. – dtech
@MartinJames Yes it does. I guess that brings me to the next issue then: is the thread just destroyed when the program is over or does it end up leaking? – edaniels
In most OS, the process OS threads are the first things to get stopped. Only when all process threads have been stopped is it safe for the OS to start releasing other resources - sockets, fd's, memory. If you terminate your process, the OS thread will go, then the objects/structs that encapsulate the OS thread into a Qt thread will go later. If your thread is only created once, and is expected to last until process termination, don't worry about trying to explicitly manage its lifetime. – Martin James

2 Answers

1
votes

http://qt-project.org/doc/qt-4.8/objecttrees.html

Qt does clean up better and parenting better if things are placed on the heap.

When QObjects are created on the heap (i.e., created with new), a tree can be constructed from them in any order, and later, the objects in the tree can be destroyed in any order. When any QObject in the tree is deleted, if the object has a parent, the destructor automatically removes the object from its parent. If the object has children, the destructor automatically deletes each child. No QObject is deleted twice, regardless of the order of destruction.

The documentation then goes on to show how it can fail if it is put only on the stack.

Hope that helps.

0
votes

Honestly, there aren't many cases where you can put a QThreadon the stack and do something useful with it before the function returns (and the thread destroyed). Maybe if you block the main thread and wait for the extra thread, but that... somehow defeats the purpose of using an extra thread. If you are going to block the main thread to wait the extra thread, you might as well do the work in the main thread.

The other case where this may apply is if you use the QThread as a class member instead of a QThread * - in this case it will work, but you lose control over the lifespan of the thread, which may not be ideal. If you have a more static usage scenario - you could do that and save yourself the horrible overhead of dynamic memory allocation...

At any rate, the overhead of allocating a single QThread dynamically is negligible and should be no cause of concern.