5

Is there a clean way to check on the current size of Qt's main application queue? Since I'm emit'ing quite a bit of signals, I'd like to monitor how big of a delay there is in processing the slot's on the Ui thread.

For example, after:

emit Signal();
emit Signal();
emit Signal();

I'd expect to be able to call something like this, which would tell me how many of those Signals are still left to process.

QApplication::checkQueueSize();
tinkertime
  • 2,972
  • 4
  • 30
  • 45
  • I've not come across anything like that; just how many signals being emitted do you think is a lot? Are you having any particular performance problems? – TheDarkKnight Jun 17 '13 at 16:23
  • no specific problem, just want to open up a peephole in case of issues in the future – tinkertime Jun 17 '13 at 16:42
  • Just to clarify, so you are using queued connections? – hyde Jun 17 '13 at 17:16
  • yep, using queued connections – tinkertime Jun 17 '13 at 19:02
  • Well, Qt has been around for a while and is used by many commercial programs, so if you do run into problems of flooding emitting of signals, it's likely due to the design of the program more than the slot / signal system. – TheDarkKnight Jun 18 '13 at 07:26
  • Does this answer your question? [How to Monitor Qt Signal Event Queue Depth](https://stackoverflow.com/questions/44440584/how-to-monitor-qt-signal-event-queue-depth) – Jason C May 16 '21 at 19:07

3 Answers3

2

Just to followup, I've decided to go with a solution that instead will allow me to measure the latency through the queue. As multiple people pointed out, there is no real use-case for looking at queue size.

I've implemented this by mapping a timestamp from before "emit Signal" to after the slot gets called.

tinkertime
  • 2,972
  • 4
  • 30
  • 45
  • There's an use case: monitoring whether the thread has stuff to do or if it can focus on a background task. – Tomáš Zato Apr 30 '19 at 10:59
  • Another use case I met: I'm developing an application where you move from one screen to the other, there is a stack keeping the path. pressing Escape come back to the previous screen. Now, when you open a QMessageBox or dialog, if you leave it with Escape, the event is not removed from the queue, and you leave the screen as well (as if you pressed Escape two times). For me this is a bug in Qt. The problem is there is no way I know to differentiate if the dialog was left by a click or the Escape key (this issue occurs possibly with the Enter key as well, but my application is not impacted). – Jacques Nov 21 '20 at 12:00
  • In my case, I'll try to use QCoreApplication::installNativeEventFilter etc... – Jacques Nov 21 '20 at 12:05
  • Another use case for monitoring queue size is that the queue size has an upper limit, after which you'll start dropping events. In a high-latency but high-throughput situation you'd be fine, but in a high-latency + low-throughput situation, latency isn't necessarily an indicator of "fullness". – Jason C May 16 '21 at 19:14
2

Imo, it should be possible (if only for logging/tracing purposes) to get information about a QThread's event queue size.

It's possible to get the size of the postEventList for a particular thread using the following snippet:

#include <QThread>
#include <private/qthread_p.h>

int getEventQueueSize(QThread* thread)
{
    auto threadData = QThreadData::get2(thread);
    QMutexLocker locker(&threadData->postEventList.mutex);
    return threadData->postEventList.size();
}

You need to take special care w.r.t. the used include paths, because the paths to private/qthread_p.h and private/qobject_p.h need to be provided. So in addition to the usual includes, you need to add:

g++ ... -isystem /usr/include/qt5/QtCore/5.7.1/QtCore ...

Disclaimer: Use at your own risk. Since this touches the internals of Qt, and is probably unintended use, take extra care when using this. There may be a chance for a deadlock when the postEventList.mutex is locked (as in the above example). Also note that QVector is not threadsafe (postEventList is a QVector) and postEventList.mutex is non-recursive.

Bram
  • 119
  • 2
0

You probably already know that there's the QApplication::hasPendingEvents() from QAbstractEventDispatcher.

This is for Qt4, but after taking a quick look at the Qt5 source it looks like it's still not available:

How to intercept ALL signals emitted by a given event in QT?

Community
  • 1
  • 1
Son-Huy Pham
  • 1,899
  • 18
  • 19
  • the hasPendingEvents function is similar to what i'm looking for, but the actual int-value size instead of the returned boolean. Ashame that they seem to only expose the boolean – tinkertime Jun 18 '13 at 15:55
  • True, but from what little I've seen (esp via debugger), the implementation is pretty straight forward. I've never needed to analyze signals and slots at that level. Starvation will probably be caused by busy-waits, network connectivity, blocking calls, etc - In some cases, the call to QCoreApplication::processEvents() will help with GUI repsonsive-ness. Note that it will execute ALL queued events - which might imply why there isn't a need for the size of the internal event queue. – Son-Huy Pham Jun 18 '13 at 16:10