Important: Please read the Qt Code of Conduct -

[Solved] Moving a worker object to a thread

  • Basically I am follwing the first example in QThread. My object sends a signal when finished. This signal I have connected to quit() method of the QThread object.
    To my understanding this should stops the thread's event loop which is hosted by run.
    However, when checking if the thread object is still running when checking isRunning(). Is this behaviour correct?

    This is on Win7 64 bit with Qt 5.4,1 MinGW compilation.

  • Hi,

    could you show your code?
    I think is a better Idea (like in the example) to call the quit() slot from the COntroller and not from the Worker.

    If you really heve/want to do it I suggest to use Qt::QueuedConnection as ConnectionType in your connect()

    connect(worker, &Worker::done, &workerThread, &QThread::quit, Qt::QueuedConnection);

    in that way the quit() slot will be executed in a new eventLoop processing

  • @mcosta
    Thanks for reply.

            MyStuff *myStuff = new MyStuff ( currentEpo, WorkingDir );
            myStuff->moveToThread ( &MyDownLoadThread );
            connect(&MyDownLoadThread, &QThread::finished, myStuff, &QObject::deleteLater);
            connect(this, &OrbitHandling::smytartMyDownLoad, myStuff, &MyStuff::sltStart );
            bool boo = connect ( myStuff, SIGNAL ( sigFinished() ), &MyDownLoadThread, SLOT ( quit() ) );
            assert ( boo );
            emit startMyDownLoad();

    MyDownLoadThread is a QThread object and MyStuffthe worker class.

  • Hi,

    in that code, where you check if MyDownloadThread is still running?
    How do you know when the thread has finished??

  • @mcosta
    That is not in this part. I have a timer loop running. There I am checking isRunning().

        qDebug() << "MyDownloadThread is " << MyDownLoadThread.isRunning();
        if ( MyDownLoadThread.isRunning() ) 
        // restart download hours later 

    The download thread is basically downloading some files and writes them to disk. So, I can simply look at the disk for checking. Also I have set a breakpoint where the signal sigFinished() is emitted. Actually I had to set the break point, where another signal is emitted but this one is connected to sigFinished(). The thread stopped in the debugger and therefore, I think the signal is emitted.

    The actual download is pretty fast most of the time.

  • @mcosta said:


    is this object a QThread instance or a subclass??
    Have you tried to use Qt::QueuedConnection in connect() ??

  • @mcosta said:


    It is a QThread instance.

    @mcosta said:

    Have you tried to use Qt::QueuedConnection in connect() ??

    Just did it is the same.

  • I found the issue. It had nothing to do with QThread.
    I had a problem in the logic. The original signal is sent twice. I have connected in worker class the signal of another instance to an internal slot, which cleans up already. Subsequently, I did the connection of the same signal to signal of the worker.

    Exchanging the connects did the trick. The internal clean-up did already kill the original signal transmitting instance. Therefore, the signal was never handed to outside.
    Now, the signal is first handed out and afterwards the internal slot is called. Need to check now if there could be a new problem.

    Anyway thanks for your help.

  • You're welcome,

    BTW, I suggest to not call quit() from the Worker; in the future you may use the same thread with several Workers. From design point of view I prefer stop the thread from the object that create it

  • @mcosta
    You seem to answer my next question. You basically can shift another worker object to the thread while the first might still run.
    Is that correct?

  • Yep,

    you can move as many objects you want in a single thread.