views:

78

answers:

1

Hi

for some time I am fiddly now to get a massive time/cputime drain action running behind a nicly responding UI. Unfortunatly I can't seem to get it running and "I think" the problem is that the slot is not processed in the QThread worker but the GUI thread. The ThreadIDs differ as expected though.

I allready read this http://doc.trolltech.com/4.6/threads-qobject.html and used googel and SO search but nothing that really helped me. Probably its something stubborn I just don't see.

Below is my cutdown code (Note: a png named "dummy1024x1024.png" is required in the same folder as the binary):

main.cpp

#include <QtGui>
#include "dummy.h"

int main(int argc, char** argv)
{
    QApplication app(argc, argv);
    Dummy d(NULL);
    d.show();
    qDebug() << "App thread " <<  QThread::currentThreadId();
    return app.exec();
}

dummy.h

#ifndef DUMMY_H
#define DUMMY_H

#include <QWidget>
#include <QVBoxLayout>
#include <QPushButton>

#include "workerthread.h"

class Dummy : public QWidget
{
Q_OBJECT
public:
    explicit Dummy(QWidget *parent = 0);
    virtual ~Dummy();
private:
    QVBoxLayout* m_layout;
    QPushButton* m_dummy[3];
    QPushButton* m_shootcalc;
    WorkerThread* m_work;
signals:

public slots:

};

#endif // DUMMY_H

dummy.cpp

#include "dummy.h"

Dummy::Dummy(QWidget *parent) :
    QWidget(parent)
{
    m_work = new WorkerThread(this);
    m_work->start();

    m_shootcalc = new QPushButton("Calc!", this);
    connect(m_shootcalc, SIGNAL(clicked()), m_work, SLOT(expensiveCalc()), Qt::QueuedConnection);

    m_dummy[0] = new QPushButton("Dummy [0]", this);
    m_dummy[1] = new QPushButton("Dummy [1]", this);
    m_dummy[2] = new QPushButton("Dummy [2]", this);

    m_layout = new QVBoxLayout(this);
    m_layout->addWidget(m_shootcalc);
    m_layout->addWidget(m_dummy[0]);
    m_layout->addWidget(m_dummy[1]);
    m_layout->addWidget(m_dummy[2]);
    setLayout(m_layout);
}


Dummy::~Dummy()
{
    m_work->quit();
    m_work->wait();
    m_work->deleteLater();
    m_work = NULL;
}

workerthread.h

#ifndef WORKERTHREAD_H
#define WORKERTHREAD_H

#include <QThread>
#include <QPixmap>
#include <QDebug>

class WorkerThread : public QThread
{
Q_OBJECT
public:
    explicit WorkerThread(QObject *parent = 0);
protected:
    virtual void run();
signals:

public slots:
    void expensiveCalc();
};

#endif // WORKERTHREAD_H

workerthread.cpp

#include "workerthread.h"

WorkerThread::WorkerThread(QObject *parent) :
    QThread(parent)
{
}


void WorkerThread::run()
{
    qDebug() << "Thread start << " << QThread::currentThreadId();
    exec();
    qDebug() << "Thread stop << " << QThread::currentThreadId();
}

void WorkerThread::expensiveCalc()
{
    qDebug() << "start pixie loading.... " << QThread::currentThreadId();
    QPixmap* pixies[16384];
    for (int i=0; i<16384; ++i)
    {
        pixies[i] = new QPixmap("./dummy1024x1024.png");
        if (i>0)
            delete pixies[i-1];
        msleep(1);
    }
    delete pixies[16384-1];

    qDebug() << "loaded pixies " <<  QThread::currentThreadId();
    qDebug() << "";
    qDebug() << "";
    qDebug() << "";
    qDebug() << "";
}

Thanks for any help/tip/reply

+3  A: 

Proper usage of QThread is a common problem among Qt users. This blog post at Qt Labs explains it nicely.

In short, you should not subclass QThread to contain code that you want to run in that thread. You should wrap your code up in a QObject subclass, instantiate it and use a QObject::moveToThread to move your object into the QThread context so that processing will occur in the context of that QThread. You can then have slots in your QObject subclass that can safely be connected to another thread but will run in the context you expect.

Some may argue that subclassing QThread should be fine if you can easily fit what you want to do inside the run() method and don't need much (or any) external interaction but even in this simple case I would favor a separate class for better encapsulation.

Arnold Spence
and to describe the actual problem: the QThread qobject itself lives in the main thread, not in the thread itself represents (!). The separation Arnold describes should make that clearer.
Frank
Thanks, yes, the QThread object "lives" in the main thread, so signals to it are processed in the main event loop which is what the OP is seeing.
Arnold Spence
there was an article in the german "Linux Magazin" a while back, about this problem. And there is some code available on github for workerthreads which work correctly with signals/slots. See here: http://github.com/picaschaf/Qt-Worker-Thread That might be what you are looking for.
smerlin