[Qt-interest] emit signal from spawned thread

Guido Seifert wargand at gmx.de
Sat Aug 20 22:52:21 CEST 2011


> Not yet: you haven't given a reason why you think it cannot work. And I can 
> tell you why you have no reason: because there isn't any. It just works 
> because there's no reason not to work.

Ok, never assume, because......
I now actuallt tried it myself. I am not sure, what the original
poster did wrong, and still not 100% sure why it works, perhaps I
really should take a peek into the concurrent code, but it does work.
 
> > How does QtConcurrent::run work? I take an arbitrary function, which
> > does not even need to be a member function, let alone a member from a
> > class, which inherits QObject and pass it to QtConcurrent::run.
> 
> It calls that function from the worker thread, once a worker thread from the 
> pool is free. That's all.

Must see code, to fully understand. Though I slowly get the idea. :-)

> > This function is somehow wrapped and executed in a thread from
> > the global thread pool. When a signal is emitted from this function,
> > isn't it emitted in the context of this 'unnamed' QThread object
> > from the global thread pool and NOT in the context of the class X?
> 
> No. A signal belongs to one class only. There's no such thing as "context" as 
> you mention. A signal is just a regular function, whose body is written by 
> moc. It doesn't know what its caller is: all it knows is the ID that moc wrote 
> into it.

No context of class. I meant object. But even for objects 'context' is probably
mistakable. 

> > And since there is no way to get a pointer or other reference to this
> > internal QThread object, how on earth can a signal/slot connection be made?
> 
> In your example: the function that was run is X::y and the signal is X::s. If 
> you can call a non-static member function, you have an object of class X (say, 
> X x). So you can just write:
> 
> 	connect(&x, SIGNAL(s), something, SLOT(something));

Yep, tried it and it worked. 
I thought the thread pool is really implemented as a pool of QThread
objects, when a function is executed via QtConcurrentRun, the function
is somehow passed to one of those QThread objects. So not &x has to be
connected, but the QThread object. 

After you told me the function is just called from the worker
thread... feel a bit stupid. Thought by far to complicated. :-(

Guido



More information about the Qt-interest-old mailing list