【发布时间】：2010-11-18 21:22:12
【问题描述】：
我不确定 Qt 4.5 中信号/槽机制的性质。发出信号时，是阻塞函数调用还是线程？这么说
emit GrabLatestData();
// proceed with latest data
在进行下一行之前是否会解决所有信号/槽链？
【问题讨论】：
【发布时间】：2010-11-18 21:22:12
【问题描述】：
laalto 上面的回答是正确的。还有一点：如果你所有的 QObjects 都属于同一个线程并且你没有手动指定排队的连接，那么连接到信号的槽的执行是同步发生的——所有的处理都将在 'emit 之后的下一行之前完成' 陈述。由于这是最常见的情况，您的问题的答案通常是“是”。
signals and slots across multiple threads 上的文档可能对您有所帮助。
【讨论】：
这取决于。来自documentation：
当一个信号发出时，与其相连的槽通常会立即执行，就像一个普通的函数调用一样。发生这种情况时，信号和槽机制完全独立于任何 GUI 事件循环。在所有插槽都返回后，将执行
emit语句之后的代码。使用queued connections时情况略有不同；这种情况下，emit 关键字后面的代码会立即继续执行，slots 会稍后执行。
所以在正常情况下，它将是同步和阻塞的，而对于排队连接，它将是异步和非阻塞的。
【讨论】：
-
另外注意默认情况下：同一线程中的对象之间的连接是直接的（同步的），不同线程中的对象之间的连接是排队的。如果您考虑一下，这是非常合乎逻辑的。
-
@quark 这并不完全正确。对象是否在同一个线程中并不重要。发出信号的线程是否是接收对象所在的线程很重要。Qt 文档甚至弄错了。来源：Signals and slots across threads。我同意 Qt 的行为是合乎逻辑的。
最大的问题是你不知道。也就是说，如果您从班级的角度来看。当你发出时，你不知道会发生什么：
- 如果没有人连接到信号，则不会发生任何事情
- 如果来自同一线程的某人使用除 Qt::QueuedConnection 之外的任何类型连接，则调用将被阻塞
- 如果来自同一线程的某人使用 Qt::QueuedConnection 连接，则调用将是非阻塞的
- 如果来自不同线程的某人使用 Qt::DirectConnection（这样做时要非常小心！）或 Qt::BlockingQueuedConnection 连接，调用将被阻塞
- 如果来自不同线程的某人使用 Qt::AutoConnection 或 Qt::QueuedConnection 进行连接，则调用将是非阻塞的
如果有多个对象连接到信号，会变得更加难以知道会发生什么。在这种情况下，某些插槽可能已经运行，而其他插槽仍在排队。 顺便说一句，非阻塞连接不涉及线程。只有一个事件会在接收对象的线程的事件循环中发布。
【讨论】：