Qt信号（QueuedConnection和DirectConnection） [英] Qt signals (QueuedConnection and DirectConnection)

问题描述

我在使用Qt讯号时遇到问题。

我不明白 DirectConnection c $ c> QueuedConnection 有效吗？

我会感谢如果有人会解释什么时候使用这些）。

解决方案

除非你使用具有不同线程亲和力的对象，否则你不会看到很多不同。假设你有QObjects A 和 B ，它们都附加到不同的线程。 A 有一个信号 somethingChanged（）和 B handleChange（）。

如果使用直接连接

  connect（A，SIGNAL（somethingChanged（）），B，SLOT（handleChange（）），Qt :: DirectConnection）; 
  

方法 handleChange（）在 A 的线程中。基本上，就好像发出信号调用slot方法直接。如果 B :: handleChange（）不是线程安全的，这可能会导致一些（难以找到）错误。至少，你错过了额外线程的好处。

如果将连接方法更改为 Qt :: QueuedConnection （或者，在这种情况下，让Qt决定使用哪个方法），事情变得更有趣。假设 B 的线程正在运行一个事件循环，发出信号会将一个事件发布到 B 的事件循环。事件循环将事件排队，并且最终在控制返回到它时（它是事件循环）调用slot方法。这使得很容易处理Qt中的线程之间的通信（同样，假设你的线程运行他们自己的本地事件循环）。你不必担心锁等，因为事件循环序列化槽的调用。

注意：如果你不知道如何改变一个QObject的线程亲爱的，看看 QObject :: moveToThread 。

我应该澄清我的开始句子。如果您指定排队的连接，即使对同一个线程上的两个对象，它也会产生影响。事件仍然发布到线程的事件循环。所以，方法调用仍然是异步的，这意味着它可以以不可预测的方式被延迟（取决于循环可能需要处理的任何其他事件）。但是，如果不指定连接方法，则直接方法将自动用于同一线程上的对象之间的连接（至少在Qt 4.8中）。

I'm having trouble with Qt signals.

I don't understand how DirectConnection and QueuedConnection works?

I'd be thankful if someone will explain when to use which of these (sample code would be appreciated).

解决方案

You won't see much of a difference unless you're working with objects having different thread affinities. Let's say you have QObjects A and B and they're both attached to different threads. A has a signal called somethingChanged() and B has a slot called handleChange().

If you use a direct connection

connect( A, SIGNAL(somethingChanged()), B, SLOT(handleChange()), Qt::DirectConnection );

the method handleChange() will actually run in the A's thread. Basically, it's as if emitting the signal calls the slot method "directly". If B::handleChange() isn't thread-safe, this can cause some (difficult to locate) bugs. At the very least, you're missing out on the benefits of the extra thread.

If you change the connection method to Qt::QueuedConnection (or, in this case, let Qt decide which method to use), things get more interesting. Assuming B's thread is running an event loop, emitting the signal will post an event to B's event loop. The event loop queues the event, and eventually invokes the slot method whenever control returns to it (it being the event loop). This makes it pretty easy to deal with communication between/among threads in Qt (again, assuming your threads are running their own local event loops). You don't have to worry about locks, etc. because the event loop serializes the slot invocations.

Note: If you don't know how to change a QObject's thread affinity, look into QObject::moveToThread. That should get you started.

Edit

I should clarify my opening sentence. It does make a difference if you specify a queued connection - even for two objects on the same thread. The event is still posted to the thread's event loop. So, the method call is still asynchronous, meaning it can be delayed in unpredictable ways (depending on any other events the loop may need to process). However, if you don't specify a connection method, the direct method is automatically used for connections between objects on the same thread (at least it is in Qt 4.8).

这篇关于Qt信号（QueuedConnection和DirectConnection）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！