Are event loops in worker threads independent of the main event loop?

Hi,

I want to be able to handle events asynchronously, with respect to the gui (main thread)--i.e., I don't want event handling to be held up while the gui is performing a time-consuming operation like opening a file dialog. The events I need to handle are QProcess signals like readyRead().

To this end, I've created a separate thread in which the QProcess is created and started, and in which all the signal/slot connections involving readyRead() are made, and with an explicit call to exec() in run(). I thought this would provide the asynchrony I wanted. But while communication between the two processes is fine, when I open the file dialog in the main gui, event handling blocks until the dialog is open.

So I thought I would first ask a general question: Is what I want possible? Is it possible to have an event loop in a worker thread which will handle events uninterrupted while the main gui blocks on something like opening a dialog? Thanks (and please let the answer be 'yes' :) )--

Matt

Yes, but don't forget you need a "moveToThread" in your object which contains the new event loop as by default it uses the thread it was created by.

Code:

---

WorkerThread::WorkerThread()
{
  moveToThread(this);
}

---

Hi faftjuicymole,

Putting moveToThread(this) in the constructor actually made the event loop fail to work at all. Actually I don't understand how that should work--putting it in the thread constructor just moves the thread to itself, right? Maybe you can take a look at these snippets and see what the problem is:

Code:

---

MyThread::MyThread() : QThread()
{
 //   moveToThread(this);
}
 
 
void MyThread::run()
{
    myserver = new QLocalServer();
    QLocalServer::removeServer("myserver");
    myserver->listen("myserver");
    connect(myserver,SIGNAL(newConnection()),this,SLOT(NewConnection()));
 
    lsock_out = new QLocalSocket(myserver);
    lsock_in = new QLocalSocket(myserver);
 
   myprocess = new QProcess();
//    gl_proc->moveToThread(this);
    myprocess->start("myproc_filename");
 
    exec();
}
 
void MyThread::NewConnection()
{
    static int ct=0;
    switch (ct++%2) //This switch is so that the first connection gets picked up as the write socket and the second as the read socket--
              //That's how things are coded on the other end.  (I.e., this function gets called twice)
    {
        case 0:
            lsock_out = myserver->nextPendingConnection();
            break;
        case 1:
            lsock_in = myserver->nextPendingConnection();
            connect(lsock_in,SIGNAL(readyRead()),this,SLOT(ReadyRead()));
            break;
   }
}
 
void MyThread::ReadyRead() 
{
     //Read from the socket connection, lsock_in...
}

---

So, what is happening is that the readyRead() events aren't getting handled while the main event loop is blocking (otherwise, communication is fine). What have I done wrong? Thank you!

Matt

Quote:

---

Originally Posted by MattPhillips

I don't understand how that should work--putting it in the thread constructor just moves the thread to itself, right?

---

Not exactly. The object is created in the main thread, and so by doing moveToThread(this) you are actually moving the event loop to its own thread rather than the main thread. Therefore you should ensure that all connects are done after this command has executed, so they get a connection type of QueuedConnection rather than DirectConnection. This means that communication between threads is done with a queue.

As far as I remember connection types are determined during signal emission and not when connecting so it shouldn't matter where you have your connect() statements. I would call moveToThread() after the constructor of the thread, though. Of course before start() is called.

Quote:

---

Originally Posted by wysota

As far as I remember connection types are determined during signal emission and not when connecting so it shouldn't matter where you have your connect() statements. I would call moveToThread() after the constructor of the thread, though. Of course before start() is called.

---

I don't understand that :( isn't new thread created on start()? I mean that when I create new QThread object there is only one thread (thread where the QThread object was created) until I call start() method on it. Then I understand that calling thread.moveToThread(&thread) would do nothing, but as I see I'm wrong here :/

What moveToThread() does is that it sets an internal variable on the thread pointing it to the object responsible for handling its events and also moves all pending events from the thread being left to the one being moved to. As there are no events pending before the thread is started, the call results in setting the variable only.

Quote:

---

Originally Posted by faldżip

I don't understand that :( isn't new thread created on start()? I mean that when I create new QThread object there is only one thread (thread where the QThread object was created) until I call start() method on it. Then I understand that calling thread.moveToThread(&thread) would do nothing, but as I see I'm wrong here :/

---

Thats what I thought when I was playing with threads a while ago, so I did a test. I created a thread with a simple slot that did nothing but echo a piece of text via qDebug ("got event"), wait 5 seconds, and then echo another piece of text ("finished with event"). The main thread did nothing but echo "Still here" every second.

The first test did as expected, held up the main thread by 5 seconds. For the second test, I put the "moveToThread" into the constructor, and the main thread continued to run every second, and I got the two messages from the secondary thread. So since then, I have always put the "moveToThread" into the constructor. Looking around (including these forums), I found other people did the same thing - probably because it's considered initialisation code.

The main thing to remember is that, yes, there is only one OS thread for your process running at the time you call the constructor, BUT, there are two Qt threads as soon as new is called on your object that inherits QThread, and this is the reference you are passing to moveToThread()

Another thing to note, looking at your code: You can only push a thread to another thread, you can not pull a thread into another thread. So things like myObject->moveToThread(this) will not work as far as I know.

Hello,

Thanks everybody for taking a look at my thread. My bad, I should have posted the Qt warning I received when I ran my program with moveToThread(this) in the constructor (as well as when I put an equivalent statement in the main thread):

Quote:

---

QObject::connect: Cannot queue arguments of type 'string'
(Make sure 'string' is registered using qRegisterMetaType().)

---

I don't know where it thinks the arguments are--I use strings a lot in my program but nowhere in the above code as you can see. So I've added

Quote:

---

qRegisterMetaType<string>("string");

---

to the constructor, and

Quote:

---

Q_DECLARE_METATYPE(string)

---

after the MyThread declaration. The warning goes away, but now there are new problems where the socket communication works only partially. I don't know quite what is going on there, I'll post again when I've clarified things. I don't understand though why Qt's meta-object system would care about the string type here though, maybe something else is going on?

Matt

ReadyRead() is a public slot and run() is protected void...

Quote:

---

Originally Posted by MattPhillips

Hello,

Thanks everybody for taking a look at my thread. My bad, I should have posted the Qt warning I received when I ran my program with moveToThread(this) in the constructor (as well as when I put an equivalent statement in the main thread):

Quote:

---

QObject::connect: Cannot queue arguments of type 'string'
(Make sure 'string' is registered using qRegisterMetaType().)

---

I don't know where it thinks the arguments are--I use strings a lot in my program but nowhere in the above code as you can see.

---

What about any other QObject::connect calls in your program... are you sure you’ve identified which statement is producing this warning?

Unless there’s a Qt bug somewhere, I think the fact that this message occurs when you include a QObject::moveToThread call and not when you don’t means that somewhere a connect is changing from direct to queued, and it passes a string parameter.

Hello,

So fatjuicymole, you were right. moveToThread(this) + qRegisterMetatype() in the ctor solved the problem. And qRegisterMetaType() was required only because, in part of the code I had cut out in order to make the example more compact for posting, I emitted a signal (via another function call) which contained a string argument. Running it with that commented out produced no warning. Now I have a problem whereby sent messages pile up in the 'client' process unless I put in a 20ms pause in between each one, but that looks like a separate issue. Thanks so much, I think this would have taken me quite awhile without your help--moveToThread() is not referenced in the QThread documentation.

Matt