How to check if an event loop has pending events outside of a thread?

Question

Calling QCoreApplication::hasPendingEvents() or QAbstractEventDispatcher::instance()->hasPendingEvents() inside of a thread works just fine. However, outside of it, the latter one (with appropriate parameter) always returns false (former cannot be used outside, because it refers to the thread from which it is called).

Here is a complete code:

#include <QCoreApplication>
#include <QAbstractEventDispatcher>
#include <QThread>
#include <QDebug>

bool hasPendingEvents(QThread *thread = 0) {
  return QAbstractEventDispatcher::instance(thread)->hasPendingEvents();
}

class MyObject: public QObject {
  Q_OBJECT

public slots:
  void Run() {
    qDebug() << __LINE__ << hasPendingEvents() << QCoreApplication::hasPendingEvents();
    QThread::sleep(1);
  }
};

int main(int argc, char *argv[]) {
  QCoreApplication app(argc, argv);

  QThread thread;
  MyObject t;
  t.moveToThread(&thread);
  thread.start();
  for (int i = 0; i<4; ++i) QMetaObject::invokeMethod(&t, "Run", Qt::QueuedConnection);

  for (int i = 0; i<10; ++i) {
    QThread::msleep(500);
    qDebug() << __LINE__ << hasPendingEvents(&thread) << hasPendingEvents(t.thread());
  }
  return 0;
}

#include "main.moc"

Here is the output:

15 true true
31 false false
31 false false
15 true true
31 false false
31 false false
15 true true
31 false false
31 false false
15 false false
31 false false
31 false false
31 false false
31 false false

Why doesn't QAbstractEventDispatcher.hasPendingEvents() work outside of a thread? Maybe there is an alternative?

Note that `&thread == t.thread()`, so there's no reason to check the same thing twice. — Kuba hasn't forgotten Monica, Jan 31 '14 at 19:36

score 3 · Accepted Answer · edited May 23 '17 at 10:31

3

What you're showing might be a Qt bug. Alas, you might not need to checking this way if another thread has any pending events.

The only reason I see that you might want to do this is to manage your own thread pool and move objects to threads that are not "busy". You'd keep a list of "busy" and "available" threads. That's what QAbstractEventDispatcher::aboutToBlock signal is for. Your thread pool should connect to this signal for every thread it creates, and add the thread to the "available" list upon reception.

If, on the other hand, you're trying to use it to implement some event compression, that's really the most awkward way to go about it. In another answer, I show how to implement custom event compression, and also how to compress signal-slot calls.

edited May 23 '17 at 10:31

Community

1
1

answered Jan 31 '14 at 19:42

Kuba hasn't forgotten Monica

95,931
16
151
313

@AlexP So, Thiago agrees with my hunch: you really should not be doing things this way. Care to divulge why do you need to call it? It really shouldn't be necessary. I haven't ever had a need for it. – Kuba hasn't forgotten Monica Feb 03 '14 at 23:32
I am working on a task that consists on many smaller and similar subtasks. The main task can be updated (hence subtasks need to be canceled and relaunched), also result of each subtask needs to be reported to the main thread. So, as you presumed, with hasPendingEvents() I wanted to make an ugly event compression. I know there is a QtConcurrent, but its future appears to be uncertain: http://stackoverflow.com/a/19973345/796120 – AlexP Feb 04 '14 at 07:58

How to check if an event loop has pending events outside of a thread?

1 Answers1