How to combine own message loop and Qt event loop?

Question

I have a class derived from QThread: class MyClass : public QThread. In the run method I have "my own" message loop:

run() { 
  // exec(); // while not reached    
  while (_runMessageLoop && ...) {
    hr = CallDispatch(.....);
    if (hr== 0) QThread::msleep(100); 
    // QCoreApplication::processEvents(); // Does not work
  }
}

Since exec() is not executed, I have no Qt event loop. This obviously causes signal / slots not to work correctly. Is there any chance to combine the Qt and my own message loop? Or do I need a frequently firing timer in order to do what I have accomplished in my infinite loop?

score 1 · Accepted Answer · answered Oct 24 '12 at 17:05

1

The right way "Qt-wise" is to use a timer and let Qt manage the event loop.

If you need to depend on external things, you can use things like QAbstractSocket to send events when data comes in over an external socket, eg.

answered Oct 24 '12 at 17:05

Wes Hardaker

21,735
2
38
69

And running a timer firing frequent 100ms updates is no problem? – Horst Walter Oct 24 '12 at 17:11
1

But more generically speaking: the best idea is to figure out what you need to do based on external triggers, if at all possible, and use those triggers instead. But whether 100ms timers are a problem is something you'll need to test, as it depends on what you're doing *during* those 100ms! – Wes Hardaker Oct 24 '12 at 17:13
"Your code above is already doing that!". Yep, but without timers. I was concerned about the overhead timers might involve. – Horst Walter Oct 24 '12 at 17:18
I don't think the timer overhead will be bad. But I'd love to see both implementations tested and measured to be sure! – Wes Hardaker Oct 25 '12 at 13:35
I have changed my code to timers, `CallDispatch` is now encapsulated and repeatedly called by a timer. The signal / slots issues disappeared, I can not observe any considerable overhead. However, I guess there is some minor overhead involved: "As a special case, a QTimer with a timeout of 0 will time out as soon as *all the events in the window system's event queue have been processed*." (QT Doku: http://doc.qt.digia.com/qt/qtimer.html). The biggest difference I have noticed is due to the fact, that my Dispatch now runs in the GUI thread (correct?), making output much easier. – Horst Walter Oct 25 '12 at 14:02
Well, it was likely running in the GUI thread before as well, unless you specifically wrote a multi-threaded application. And yes, it can't promise you a true 10ms delay between calls because it would depend too much on what else is happening and what other events need processing. But that was true in your code above as well, so it's really not a change. I'm definitely glad to hear it's working!!! And thanks for the report on how well it worked! – Wes Hardaker Oct 26 '12 at 13:27

score 1 · Answer 2 · answered Oct 24 '12 at 22:43

This is not really the answer for implementing the event loop correctly, I'm fairly sure there is a way, but more of a workaround:

Start the thread normally, exec() and all, and connect the start signal to a slot (make sure it gets called in the right thread), then put your loop there, and call Qt's processEvents() in that loop. That makes sure Qt event loop gets properly set up.

How to combine own message loop and Qt event loop?

2 Answers2

Linked