QT : How to determine if the event processor is busy

Question

In my current Qt application I am attempting to shut it down using

QCoreApplication::quit();

Now it takes more than a minute for the application to shutdown. I believe this is because the event processor of the main form is busy. My question is : Is there a way for me to determine what the cause of this might be. Here are somethings that I suspect

1-Queued Connections. I have a lot of queued connections. Maybe some of those connections dont get processed

2-Event Loop. May be the event loop is busy doing something that I dont know (expect)

Any suggestions on what I could do to check why the app takes so long to close ?

Update:

I tried QCoreApplication::hasPendingEvents() and that returns true

Did you try to call `QCoreApplication::hasPendingEvents()`? What does it return? — vahancho, Aug 06 '14 at 14:45
Use some profiler to find source of this delay. Do not guess what is causing problem since you will be fixing wrong things. in Linux you have a valgrind. Simple pause button in debug mode also can help to spot the problem — Marek R, Aug 06 '14 at 14:52
[This answer](http://stackoverflow.com/a/25118309/1329652) shows you how to detect threads with busy event loops. It's then a trivial matter to pause the application in a debugger and look at what's on the stack trace. — Kuba hasn't forgotten Monica, Aug 06 '14 at 15:00
@KubaOber sweet little program. Did you wrote it on your spare time? — UmNyobe, Aug 06 '14 at 15:13
You don't need a profiler. Hit the pause in your debugger and see where the main thread is stuck. Use a debug build of Qt. — Kuba hasn't forgotten Monica, Aug 06 '14 at 15:17

score 1 · Answer 1 · answered Aug 06 '14 at 15:16

There's no such thing as queued connections that are "not" processed, or event loop being "busy". An event loop is, essentially, this (in C++ pseudocode):

forever {
  while (! nativeEventQueue.isEmpty()) {
    QueueEntry entry = nativeEventQueue.take_first().convert();
    QCoreApplication::sendEvent(entry.object, entry.event);
    delete entry.event;
  }
  while (! eventQueue.isEmpty()) {
    QueueEntry entry(eventQueue.take_first());
    QCoreApplication::sendEvent(entry.object, entry.event);
    delete entry.event;
  }
  waitFor(eventQueue, nativeEvents);
}

All of the event processing is done by sending some QEvent to a QObject. That's all that the event loop does. Some events result in the signals being emitted. It's not the event loop that is busy, it's the code that runs in the QObject::event and overridden implementations! This code blocks the event loop, since when it runs, the event loop's code is in the same thread and is on the call stack - it can't run.

Your code in slots connected to signals in Qt widgets and other objects is really executed while QCoreApplication::sendEvent and QCoreApplication::notify is on the call stack, with the event loop (a QAbstractEventDispatcher) somewhere deeper in the call stack, and finally a QEventLoop under it.

If your code executes at a pace that is slower than the events are added to the queue, you will have problems.

This trivial example demonstrates such code. In real programs it'll be of course "obfuscated", but the problem often reduces to:

void Class::customEvent(QEvent * ev) {
  ...
  QCoreApplication::postEvent(this, new EventFoo(...));
  ...
  QCoreApplication::postEvent(this, new EventFoo(...));
  ...
}

The explicit event posting can be expressed very differently. For example, it could be you sending a signal to yourself:

void Class::mySlot() {
  ...
  emit signal1();
  ...
  emit signal2();
}

If both signal1 and signal2 are connected to mySlot through a queued connection, your application will run out of memory, as the event queue will only grow, never shrink. It may still appear responsive.

QT : How to determine if the event processor is busy

1 Answers1