Important: Please read the Qt Code of Conduct -

QThread finished() connected to deletelater of a QObject

    • 0 down vote favorite

    I have thought a lot and read lot of articles before asking this question here. None of the articles gave me a proper answer.

    @ QThread* thread = new QThread;
    Worker* worker = new Worker();
    connect(worker, SIGNAL(error(QString)), this, SLOT(errorString(QString)));
    connect(thread, SIGNAL(started()), worker, SLOT(process()));
    connect(worker, SIGNAL(finished()), thread, SLOT(quit()));
    connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
    connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));

    Worker object has the affinity of the new thread.

    1 > Worker finished signal will call quit() on the thread. This will end the thread's event loop and initiates the thread finished signal.

    2 > Worker finished signal is connected to the worker deleteLater(). According to deleteLater() documentation

    Schedules this object for deletion. The object will be deleted when control returns to the event loop. If the event loop is not running when this function is called (e.g. deleteLater() is called on an object before QCoreApplication::exec()), the object will be deleted once the event loop is started. Note that entering and leaving a new event loop (e.g., by opening a modal dialog) will not perform the deferred deletion; for the object to be deleted, the control must return to the event loop from which deleteLater() was called. Note: It is safe to call this function more than once; when the first deferred deletion event is delivered, any pending events for the object are removed from the event queue.

    So when there is no eventloop, since the thread is already exiting and it has already raised the finished signal and we will no longer start the same thread again. In this case the deleteLater() will never be handled since the event loop doesn't exist and and worker object will not be deleted at all. Does this not create a memory leak.?

    @ connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
    connect(worker, SIGNAL(finished()), thread, SLOT(quit()));@

    If we think that swapping the two lines will fix the problem, then I have another question. QT clearly states that the order the slots getting called when a signal is emitted is undetermined

    There are bunch of comments in the article link mentioned above . Even the author was not able to answer the question completely

  • Well I'll tell you what works for me. I'm unsure if it suits your needs, but when I have some worker object(s) that must spend all theyr lifetime in a QThread, I subclass QThread like so (written just yesterday for server app with console command input):
    @#include <QThread>

    class InputThread; // event calling qobject, okay
    class Server; // worker, smth like TcpServer

    class ServerThread : public QThread
    explicit ServerThread(InputThread* input);
    void run();

    public slots:
    void msgQuit(); // external quit request

    InputThread* m_Input; // store it to connect in run
    Server* m_Server; // worker itself

    @#include "serverthread.hpp"
    #include "inputthread.h"
    #include "server.h"

    #include <QCoreApplication>

    ServerThread::ServerThread(InputThread* input) :
    QThread(0), m_Input(input), m_Server(0)
    connect(m_Input, SIGNAL(destroyed()), SLOT(msgExit()));

    void ServerThread::run()
    m_Server = new Server; // first instantiate worker
    // have some slots here and there
    connect(m_Input, SIGNAL(startServer()), m_Server, SLOT(startServer()));
    connect(m_Input, SIGNAL(stopServer()), m_Server, SLOT(stopServer()));
    connect(m_Input, SIGNAL(listServer()), m_Server, SLOT(listServer()));
    connect(m_Input, SIGNAL(postMessage(QString)), m_Server, SLOT(postMessage(QString)));
    //now we can start loop

    exec&#40;&#41;; // it will return when quit is called
    delete m_Server; // so after quit we remove worker
    QCoreApplication::exit(0); // optional

    void ServerThread::msgExit()
    quit(); wait(3000); /* ask it to quit, and wait a bit for thread to exit, usually takes about 0 of 3000 msec /
    if(isRunning()) terminate(); /
    but kill it for sure if failed to finish within 3000 sec */

    So the idea is to really create and connect worker in thread, and delete it in thread function as well. For that we have to remember any pointers to objects which we want to connect to. In constructor we only connect things to this QThread, if needed. In run we init worker and since exec() does not return before quit - we can place deletion right after.

    P.S. not QT (QuickTime) but Qt

  • 'slowpoke mode detected'

    Something just crossed my mind.. What if you connect worker::finished to worker::deleteLater and worker::destroyed to thread::quit ?

Log in to reply