Using QTimer in a QThread

[Cruz]

I don't get it. I want to start a thread that periodically executes a function using a timer.

Thread::Thread(QObject *parent) : QThread(parent)
{
	start();
}
 
void Thread::run()
{
	QTimer t;
	connect(&t, SIGNAL(timeout()), this, SLOT(tick()));
	t.start(100);
	//t.moveToThread(this);
	exec();
}
 
void Thread::tick()
{
	qDebug() << currentThreadId() << "tick()";
}
 
 
 
class ThreadTest : public QWidget
{
 
    Thread thread;
 
   ...
};
 
ThreadTest::ThreadTest(QWidget *parent)
    : QWidget(parent)
{
	qDebug() << QThread::currentThreadId() << "is the main thread.";
}

Thread::Thread(QObject *parent) : QThread(parent)
{
	start();
}

void Thread::run()
{
	QTimer t;
	connect(&t, SIGNAL(timeout()), this, SLOT(tick()));
	t.start(100);
	//t.moveToThread(this);
	exec();
}

void Thread::tick()
{
	qDebug() << currentThreadId() << "tick()";
}



class ThreadTest : public QWidget
{

    Thread thread;

   ...
};

ThreadTest::ThreadTest(QWidget *parent)
    : QWidget(parent)
{
	qDebug() << QThread::currentThreadId() << "is the main thread.";
}

To copy to clipboard, switch view to plain text mode 

And the output I get is:

0x12b8 is the main thread. 
0x12b8 tick() 
0x12b8 tick() 
0x12b8 tick() 
0x12b8 tick()
...

0x12b8 is the main thread. 
0x12b8 tick() 
0x12b8 tick() 
0x12b8 tick() 
0x12b8 tick()
...

To copy to clipboard, switch view to plain text mode 

Obviously, the timer is still running on the main thread. Using the moveToThread() doesn't make a difference. What's not right about this?

Changing the timer to an infinite loop with sleep() works though.

void Thread::run()
{
	forever
	{
		tick();
		sleep(1);
	}
}

void Thread::run()
{
	forever
	{
		tick();
		sleep(1);
	}
}

To copy to clipboard, switch view to plain text mode 

0xa04 is the main thread. 
0xfa0 tick() 
0xfa0 tick() 
0xfa0 tick() 
...

0xa04 is the main thread. 
0xfa0 tick() 
0xfa0 tick() 
0xfa0 tick() 
...

To copy to clipboard, switch view to plain text mode 

[MarekR22]

Problem is that you are doing that wrong!

class TestClass : QObject
{
    Q_OBJECT
public:
    TestClass(QObject *parent=0);
 
public slots:
    void tick();
};
 
TestClass::TestClass(QObject *parent) : QObject(parent)
{
     QTimer *t = new QTimer(this);
     connect(t, SIGNAL(timeout()), this, SLOT(tick()));
}
 
void TestClass::tick()
{
	qDebug() << currentThreadId() << "tick()";
}
 
// and somewhere
QThread *thread = new QThread(something);
TestClass *object = new TestClass(); // can't pass parent!!!!!!
object->moveToThread(thread);
thread->start();
 
....
delete object;
thread->WaitFor();
// delete thread;

class TestClass : QObject
{
    Q_OBJECT
public:
    TestClass(QObject *parent=0);
    
public slots:
    void tick();
};

TestClass::TestClass(QObject *parent) : QObject(parent)
{
     QTimer *t = new QTimer(this);
     connect(t, SIGNAL(timeout()), this, SLOT(tick()));
}

void TestClass::tick()
{
	qDebug() << currentThreadId() << "tick()";
}

// and somewhere
QThread *thread = new QThread(something);
TestClass *object = new TestClass(); // can't pass parent!!!!!!
object->moveToThread(thread);
thread->start();

....
delete object;
thread->WaitFor();
// delete thread;

To copy to clipboard, switch view to plain text mode 

[high_flyer]

Problem is that you are doing that wrong!

I don't see what he is doing wrong, in respect to the link you posted, except for what he tried in the second bit, which is wrong because you need to be in the "other thread" to call moveToThread().
The link you provided is talking about using moveToThread() wrong usage, and that you should not always use a subclass of QThread for your threads.
But there are many cases where this is the RIGHT way to go.
Even if from an OOP design point of view this is wrong, from implementation point of view this still should work (the original code with out moveToThread()).
And if it doesn't we need to understand why.

His code is almost the same as the example code QThread docs, just that he uses a QTimer and not a QTcpSocket.
Since the QTimer is allocated in run() its should have the thread affinity of the new thread, and from what the OP shows, it looks like its affinity is to the main GUI thread, which is surprising.

My guess is that it has to do with calling start() in the thread constructor.
Try removing the start() form the constructor, and call it normally from outside, see if this changes things.