事件队列与用于跨线程信号/槽的队列(在 Qt 中)相同吗?
我想知道 Qt 中的排队事件对于事件和信号是否相同(信号不是从与接收槽相同的线程发出的,因此会排队。)
所以要清楚,我们是否有:
- 一个事件队列
- 一个信号队列(由于在不同线程中发出/槽,无法直接执行)
或者我们是否有
- 一个用于事件和信号的队列
I'm wondering if a queued event in Qt is the same for event and for signals (which are not emitted from the same thread as the received slot, and therefore enqueued.)
So to be clear, do we have:
- one queue for event
- one queue for signal (which can't be executed directly, due to emit/slot in different threads)
or do we have
- one queue for event and signal
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
有一个队列。 invokeMethod() 产生一个 QEvent,它是一个“QMetaCallEvent”。它的事件索引为 43,您可以在此处将其视为
QEvent::MetaCall
:http://doc.qt.io/qt-5/qevent.html#Type-enum
被放入
qmetaobject.cpp
中的队列中。 ..在哪里“invoking”触发对 QApplication 的 postEvent 的调用。这是该行的链接在撰写本文时在更新时损坏的 gitorious 链接/src/corelib/kernel/qmetaobject.cpp
line 2228没有传递“优先级”参数,因此信号/槽调用将始终Qt::NormalEventPriority。
文档中并没有按照合同规定详细说明这一点,因此我会谨慎地避免对未来每个平台和版本上的行为做出过多假设。如果您需要在程序的某些部分中为事件处理的顺序制定严格的合同,那么您最好编写自己的显式协议。
There is a single queue. invokeMethod() produces a QEvent which is a "QMetaCallEvent". It's event index 43, and you can see it here as
QEvent::MetaCall
:http://doc.qt.io/qt-5/qevent.html#Type-enum
It is put into the queue in
qmetaobject.cpp
...where "invoking" triggers a call to QApplication's postEvent. Here is the link to that lineat the time of writingat the time of updating broken gitorious links/src/corelib/kernel/qmetaobject.cpp
line 2228There is no "priority" parameter passed, so signal/slot calls will always be Qt::NormalEventPriority.
The details of this are not really contractually laid out too well in the documentation, so I'd be cautious of assuming too much about the behavior on every platform and version in the future. If you need a rigorous contract for the ordering of event processing in some part of your program, you might be best off coding your own explicit protocol.