在我当前的 Qt 应用程序中,我试图使用
QCoreApplication::quit();
现在应用程序关闭需要一分多钟。我相信这是因为主窗体的事件处理器很忙。我的问题是:我有没有办法确定这可能是什么原因。这是我怀疑的一些事情
1-排队连接。 我有很多排队的连接。也许其中一些连接没有得到处理
2-事件循环。 可能是事件循环正忙着做一些我不知道(预期)的事情
关于我可以做些什么来检查为什么应用程序关闭需要这么长时间有什么建议吗?
更新:
我试过 QCoreApplication::hasPendingEvents()
并返回 true
最佳答案
没有“未”处理的排队连接或事件循环“忙”这样的事情。事件循环本质上是这样的(在 C++ 伪代码中):
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);
}
所有的事件处理都是通过发送一些QEvent
到QObject
来完成的。这就是事件循环所做的一切。某些事件会导致发出信号。繁忙的不是事件循环,而是在 QObject::event
和重写实现中运行的代码!此代码阻塞事件循环,因为当它运行时,事件循环的代码在同一个线程中并且在调用堆栈上 - 它无法运行。
当 QCoreApplication::sendEvent
和 QCoreApplication::notify
在调用堆栈上时,您在连接到 Qt 小部件和其他对象中的信号的槽中的代码真正执行,与事件循环(一个 QAbstractEventDispatcher
)在调用堆栈的某个更深的地方,最后是一个 QEventLoop
在它下面。
如果您的代码执行速度比事件添加到队列的速度慢,您就会遇到问题。
这个简单的例子演示了这样的代码。在实际程序中,它当然会被“混淆”,但问题通常会简化为:
void Class::customEvent(QEvent * ev) {
...
QCoreApplication::postEvent(this, new EventFoo(...));
...
QCoreApplication::postEvent(this, new EventFoo(...));
...
}
显式事件发布可以有非常不同的表达方式。例如,可能是您向自己发送信号:
void Class::mySlot() {
...
emit signal1();
...
emit signal2();
}
如果 signal1
和 signal2
通过排队连接连接到 mySlot
,您的应用程序将耗尽内存,因为事件队列只会增长,不会缩小。它可能仍然显示响应。
关于c++ - QT : How to determine if the event processor is busy,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25163095/