[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