Newbie threading question

Hi,

I'm new to Qt and threading, so I'm probably missing something obvious. I'm trying to use a thread in my application (subclassing QThread), and everything seems to be working. However, when the thread goes into a time consuming operation, my whole GUI freezes up.

I have created a simplified version which is available at http://dsarkar.fhcrc.org/qtthread/. Basically, the main thread and the secondary thread both start a timer (1 and 2 seconds each) that print a message to the console when they timeout(). When I start the application, both sets of messages are printed as expected. There is a menu action that emits a signal that is connected to a slot in the thread making it sleep for 10 seconds. When this is triggered, I would have expected the main thread to keep on going. Instead, both sets of timers stop and the whole GUI freezes up for 10 seconds.

The full code is available on the website. Here are the main parts:

myMainWindow.cpp:

Code:

---

MyMainWindow::MyMainWindow()
{
    createActions();
    createMenus();
    mythread = new MyThread();
    QTimer *timer = new QTimer(this);
    connect(timer, SIGNAL(timeout()),
            this, SLOT(reportStatus()));
    timer->start(2000);
    connect(this, SIGNAL(needSleep(unsigned int)),
            mythread, SLOT(sleepFor(unsigned int)));
}
 
void MyMainWindow::reportStatus()
{
    printf("Main eventloop timeout event\n");
}
 
void MyMainWindow::createActions()
{
    sleepAct = new QAction("&Make Thread Sleep", this);
    sleepAct->setShortcut(tr("Ctrl+S"));
    connect(sleepAct, SIGNAL(triggered()),
            this, SLOT(makeThreadSleep()));
}
 
 
void MyMainWindow::makeThreadSleep()
{
    emit needSleep(10);
}

---

myThread.cpp:

Code:

---

#include <unistd.h>
 
MyThread::MyThread(QObject * parent)
    : QThread(parent)
{
    QTimer *ttimer = new QTimer(this);
    connect(ttimer, SIGNAL(timeout()),
            this, SLOT(reportThreadStatus()));
    ttimer->start(1000);
    return;
}
 
void MyThread::reportThreadStatus()
{
    printf("Thread eventloop timeout event\n");
}
 
void MyThread::sleepFor(unsigned int t)
{
    printf("Thread going to sleep for %d seconds...\n", t);
    sleep(t);
    printf("Thread waking up...\n");
}
 
 
void MyThread::run()
{
    exec();
}

---

main.cpp:

Code:

---

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    MyMainWindow mainWin;
    mainWin.show();
    mainWin.mythread->start();
    return app.exec();
}

---

Does anyone see what I'm doing wrong? Thanks,
-Deepayan

Don't include unistd.h and use QThread::sleep() instead of sleep(). Maybe this will help.

This will not work! Because:

1. Current situation

Code:

---

connect(this, SIGNAL(needSleep(unsigned int)), 
            mythread, SLOT(sleepFor(unsigned int)) , Qt::QueuedConnection);

---

This will post an event to the thread's event queue instead of calling sleepFor directly. Wrong again because sleepFor will be called from the thread's event queue and also affects the applications event dispatcher ( will freeze again ).
I have attached a screenshot for the second case. As you can see the event dispatcher does not exit until sleepFor finishes.

Solution:
Do not sleep in the event handler.

EDIT: Actually, the first case does not apply ( :) ). It is still QueuedConnections, since is another thread.

Regards

Your thread object (created in MyMainWindow constructor) lives in main thread (another name is gui thread), so all its slots are executed in main thread and that's why your GUI freezes. When I am using threads I usually create two classes. One class is a class with all slots and another is a thread class for the previous one. It looks like below:

Code:

---

// header file
class MyObjectThread : public QThread {
    Q_OBJECT;
protected:
    void run() {
        exec();
    }
};
 
class MyObject : public QObject {
    Q_OBJECT;
public:
    MyObject();
public slots:
    void slDoSomething();
private:
    MyObjectThread * thread;
private slots:
    void slThreadStarted();
};

---

Code:

---

// implementation file
MyObject::MyObject() {
    thread = new MyObjectThread();
    connect(thread, SIGNAL(started()), SLOT(slThreadStarted()));
    this->moveToThread(thread);
    thread->start();
}
 
void
MyObject::slThreadStarted() {
    // do something or nothing
}
 
void
MyObject::slDoSomething() {
    // do something
}

---

Now I am sure that MyObject lives in its own thread and its slots will be executed in own thread.

Sorry, not true. I actually tested it... Read my previous post. The same thing happens...
Anyway the thread is only started in main(), but is created in MyMainWindow.

Regards

To Danadam:

Quote:

---

this->moveToThread(thread);

---

---Won't ever work considering the thread was created in the main window (a widget ), and all widgets must live in the gui thread. You can't just move them to another thread.

Quote:

---

Originally Posted by marcel

Sorry, not true. I actually tested it... Read my previous post. The same thing happens...
Anyway the thread is only started in main(), but is created in MyMainWindow.

---

There is something wrong with your code. It uses sendEvent() to deliver the event to the queue and that causes the calling thread to be blocked. With queued connections the event should be delivered using postEvent(). Are you by any chance using Qt 4.3 beta? The effect you experience seems to fit to the blocked queued connection type.

No, it's 4.2.2.

EDIT - with the code from the first post...
Wasn't the event posted when the signal was emitted? What you see in the call stack is the posted event being processed.

Oh, I see what's wrong :) You're calling a slot from the thread and not an object created in the thread. The QThread instance lives in the thread that created the object (the main thread in this case). So when you call a slot from the QThread object, it is executed in the context of the main thread and not of the worker thread. Either move the slot to an object created in the run() method of your thread or change the thread affinity of the QThread object using moveToThread(). Just make sure to do it after the thread is actually started.

Here is a small example to demonstrate what I mean.

I think you complicated things a bit there... :) It works by calling myThread->moveToThread(myThread) right after starting the thread, in the main window constructor.
A good idea nevertheless....

Regards

I didn't complicate anything. It was just an example to show that the affinity changes and the connection type changes from Direct to Queued.

It was all about moving the event processing for the thread to the thread event handler...
It can be seen now on the call stack that the event is treated in MyThread::exec() not QApplication::exec(), as before.

That's exactly what a "queued" connection means.

Yes, I know. It was queued before, but it was treated in the GUI event handler, not in the thread's event handler. That is why it blocked the interface.

Regards

No, it wasn't queued. If you don't pass a connection type to connect() (like it is the case here) it defaults to Qt::AutoConnection, which means that when a signal is emitted and Qt iterates slots that are connected, it checks if the caller and callee live in the same thread. If so, it calls the slot directly (like in this situation). Otherwise it posts an event to the receiving thread.

BTW. I'm not sure it is reliable to change the thread affinity immediately after calling QThread::start(). The thread may not be started at that point yet. It's safer to move the object on the QThread::started() signal.

True.
Also, in the Assistant, there is stated:

Quote:

---

With auto connections (the default), the behavior is the same as with direct connections if the signal is emitted in the thread where the receiver lives; otherwise, the behavior is that of a queued connection.

---

Quote:

---

I'm not sure it is reliable to change the thread affinity immediately after calling QThread::start(). The thread may not be started at that point yet. It's safer to move the object on the QThread::started() signal.

---

True.

Quote:

---

Originally Posted by marcel

Sorry, not true. I actually tested it... Read my previous post. The same thing happens...
Anyway the thread is only started in main(), but is created in MyMainWindow.

Regards

---

I think you identified the problem correctly. After reading the docs a bit more, I realised that only objects that are created in myThread::run() actually live in the new thread. Moving things around accordingly solves my problem.

Thanks for all the quick replies.

Deepayan