-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
4.6.2, 4.7.0
-
f479c4110cdcd82863abb172777b1bf9113ffb49
Today, Thiago Macieira posted a clarification about thread affinity on the Qt-Interest mailing list (http://lists.trolltech.com/pipermail/qt-interest/2010-May/023514.html). The important bits are these:
> The signal/slot queued connection mechanism works by posting events. That's
> why a queued connection is delivered in the thread that the object is affined
> to.
>
> The only extra operation is the determination of AutoConnection: if the target
> object's thread affinity is the current thread, the signal is delivered directly
> (decays to DirectConnection). If it's another thread, it's queued (decays to
> QueuedConnection).
>
> The emitter object's thread affinity has no influence in this process. It only
> depends on the current thread, that is, the thread in which the signal is
> emitted.
The current documentation states the following, however:
"Auto Connection (default) The behavior is the same as the Direct Connection, if the emitter and receiver are in the same thread. The behavior is the same as the Queued Connection, if the emitter and receiver are in different threads."
This is wrong, since it implies that the thread affinity of the emitter influences the resolution of an AutoConnection which, according to Thiago, is not the case. Moreover, the concept of thread affinity is ambiguously alluded to as "being in a thread." The correct phrasing should be something like this:
"Auto Connection (default) The behavior is the same as the Direct Connection, if the signal is emitted in the thread to which the receiver object has affinity. Otherwise, the behavior is the same as the Queued Connection."
Documentation used as reference for this report:
http://doc.qt.nokia.com/4.7-snapshot/qt.html#ConnectionType-enum
http://doc.qt.nokia.com/4.7-snapshot/threads-qobject.html#signals-and-slots-across-threads