[Interest] Emitting a signal from a different thread than the object lives in

[Reinhardt Behm]

On Friday 26 August 2016 10:38:57 Etienne Sandré-Chardonnal wrote:
> Thanks, does that mean that the moc-generated signal member function is
> made fully thread safe?
> 
> 2016-08-26 10:36 GMT+02:00 Igor Mironchik <igor.mironchik at gmail.com>:
> > Hi,
> > 
> > On 26.08.2016 11:33, Etienne Sandré-Chardonnal wrote:
> > 
> > Hi,
> > 
> > I have an object which subclasses QThread for performing an asynchronous
> > operation. Before any objection rises about that, I know that for most
> > uses
> > QThread subclassing is not the way to go, and creating an object which is
> > pushed to a regular QThread is better, and I'm doing it 99% of the time,
> > but here it was more straightforward to simply subclass QThread and
> > overload run(), and no event loop is needed. This works fine.
> > 
> > Now I would like the run() function to make the QThread subclass emit
> > signals. If I just do "emit mySignal()" inside run(), my guess is this
> > will
> > not work unless there is a special mechanism handling this.
> > 
> > 
> > You can do it.
> > 
> > 
> > Can I do this, or do I need a full event loop, an object living inside the
> > QThread, and a queued connection between signals? (ie the regular QThread
> > use)
> > 
> > Thanks!

Your signal belongs to your QThread derived object. This does not live in the 
thread started with run().
So I think to simply connect from another thread (the one your thread-object 
is living in) might create problems. These connection would be made as 
DirectConnection, because sender (your thread-object) and receiver live in the 
same thread.

But you should be on the safe side, if you do all connections to this signal 
with explicit QueuedConnection.

-- 
Reinhardt