-1

From: http://doc.qt.io/qt-5/qthread.html#details

From Qt 4.8 onwards, it is possible to deallocate objects that live in a thread that has just ended, by connecting the finished() signal to QObject::deleteLater().

Does this mean if I connect finished() signal to QObject::deleteLater() I won't have to worry about memory leaks in the worker thread?

What objects of worker thread class is it going to deallocate on its own?

connect(workerThread, &WorkerThread::finished, workerThread, &QObject::deleteLater); From : doc.qt.io/qt-5/qthread.html#details

They have shown workerthread's object connected to deleteLater slot. Now does this mean that all objects which I allocate memory to inside the worker class will get automatically deleted?

Aquarius_Girl
  • 21,790
  • 65
  • 230
  • 411
  • **Not at all.** You are connecting the `workerThread`'s `finished()` signal **to its own** `deleteLater()`. This is not what is meant by the docs (as this will cause undefined behavior when your `workerThread` is not allocated dynamically). Instead, you need to connect `finished()` signal to a worker object's `deleteLater()`. The worker object should be living in the worker thread (by using `moveToThread(workerThread)`)... – Mike Jun 13 '18 at 07:56
  • @Mike Please show the example. What i have written there is written in the docs. – Aquarius_Girl Jun 13 '18 at 08:12
  • The quote is indeed from the docs, but it doesn't mean that you should connect the thread's `finished()` signal **to its own** `deleteLater()`. Usually, you connect the `finished()` signal **to another worker** QObject's `deleteLater()`, so that the worker object is destroyed when the thread is finished. I don't have time to provide a complete example now, but I'll try to post one later... – Mike Jun 13 '18 at 08:30
  • Does it mean that main thread's finished signal should be connected to worker's deleteLater? @Mike – Aquarius_Girl Jun 13 '18 at 08:34
  • Exactly. Usually, you don't need to subclass QThread. Instead, have a worker QObject that hosts the code that needs to be executed in the worker thread, then move that worker object to the thread and start it after connecting the finished signal from the thread to the worker's deleteLater... – Mike Jun 13 '18 at 08:44
  • @Mike The example is already in the docs. The one above the example OP referred to. – thuga Jun 13 '18 at 09:17
  • @Aquarius_Girl, the example provided in the [docs](https://doc.qt.io/qt-5/qthread.html#details) (as mentioned by @thuga) shows how this should be done... – Mike Jun 13 '18 at 12:44

2 Answers2

2

If a QThread ends (when it run() method returns) it sends the signal QThread::finished. Every QObject whose deleteLater slot is connected to this signal gets deleted.

If you connect the QThread::finished() signal to QObject::deleteLater() method of the worker object as mentioned in the documentation of QThread (http://doc.qt.io/qt-5/qthread.html#details), then the worker is deleted after the QThread has finished. All other QObjects which you have created within the worker will still exist. If you want them to be deleted too you have to either connect them to the same QThread::finished() signal or you use the parent-child-mechanism by setting the worker object as parent of the other object (either by passing it as parent in the constructor (http://doc.qt.io/qt-5/qobject.html#QObject) or by setting it explicitly with void QObject::setParent(QObject *parent) (http://doc.qt.io/qt-5/qobject.html#setParent).

Julian Mayer
  • 121
  • 4
1

What objects is it going to deallocate on its own?

The objects whose deleteLater slot you connected.

But you have it backwards, it seems: threading and object lifetimes are orthogonal issues. Just because stuff runs in some other thread doesn't mean that somehow it will leak - not unless you just totally gave up on object lifetime management.

Imagine that your objects live in the main thread. How will you manage their lifetime? Do the same thing in the worker. It's also not necessary to end the object lifetimes in the worker thread. You can push them back to the main thread, end the worker thread, and destroy them in the main thread. Etc. Threading doesn't introduce any new problems here: you had the problem from the beginning. Solve it, then add threading and it won't reappear :)

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313