CODEWITHSUNDEEP
c++qt
Rajeshwar
Rajeshwar

Reputation: 11661

QT : How to determine if the event processor is busy

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

Upvotes: 0

Views: 1144

Answers (1)

Kuba hasn't forgotten Monica
Kuba hasn't forgotten Monica

Reputation: 98495

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.

Upvotes: 1

Related Questions