[Qt-interest] Confused by dev-net wiki article: inter-thread sig-slot connections

[K. Frank]

Hi Mandeep!

On Fri, Jun 17, 2011 at 7:45 AM, Mandeep Sandhu
<mandeepsandhu.chd at gmail.com> wrote:
> Hi all,
>
> I was going through the new docs on dev net on Qthreads
> ...
> All was well with the wiki article, till I reached the section
> "Signals and slots across threads". The article shows the following
> example (see the 1st example shown):
>
> class Thread : public QThread
> {
>    Q_OBJECT
>
>  signals:
>    void aSignal();
>
> protected:
>    void run() {
>        emit aSignal();
>    }
> };
>
> /* ... */
> Thread thread;
> Object obj;
> QObject::connect(&thread, SIGNAL(aSignal()), &obj, SLOT(aSlot()));
> thread.start();
> ...
>
> It then goes on to say that the connection made above, would be a
> 'queued' connection and NOT 'direct'!

(Technically speaking, I believe the connection is an "automatic"
connection.  That is, whether to to call the slot directly (as in
a "direct" connections) or post an event to the event queue
servicing the slot (as in a "queued" connection) is decided at the
time the signal is emitted.)

> I remember (I think Thiago had mentioned it), that Qt will compare the
> thread affinity of the object that emitted the signal with that of the
> object that has the receiving slot. If they're same, a direct
> connection would be made.

I believe that this is incorrect.  (And I don't recall Thiago saying it this
way.)

> But from the wiki article, it seems that Qt is comparing the thread
> context _when_ the signal is emitted with the receivers' thread
> affinity and NOT the emitter's thread affinity.

Yes, I believe that both the Qt documentation and Thiago's explanations
say this.

That is (if you have an "automatic" connection), the thread of execution
that emits the signal is compared with the thread affinity of the receiving
object.  If they are the same, the slot is called directly; if they are
different, an event is posted to the object's event queue.  Thus, the
slot is always called by the thread of execution for which the receiving
object has affinity.

> So what is the correct answer - in the above example is it a direct or
> queued connection?

Again, technically, you have an "automatic" connection.

When the signal is emitted, it is emitted by the thread's (i.e., your
instance of your Thread object) thread of execution, which is different
that the thread of execution that instantiated both obj and thread.
Let's call the thread that instantiated obj and thread the main thread.

Because obj was instantiated by the main thread, it has thread
affinity for the main thread.  (thread, the instance of Thread, also
has thread affinity for the main thread, but that doesn't matter here.)

When thread's thread emits the signal, because the connection is
"automatic," the framework compares the thread emitting the signal
(thread's) with the thread affinity of the receiving object (the main
thread).  Because they are different, an event is posted to the event
queue being serviced by the main thread (which we might call the
main event loop).  And yes, this is what would have happened if
the connect call had set up a "queued" connection.

> I'm confused again! :(

I hope I've got this right.  Perhaps Thiago will straighten things out
if I've screwed something up here.

> Thanks,
> -mandeep

Good luck.


K. Frank