On Fri, Nov 30, 2018 at 10:49 PM Jérôme Godbout <[email protected]> wrote:
> If you use automatic connection when doing this you will run into troubles > and my be surprise by the signals sent from the thread execution (they will > act like if they were sent from the Qthread creator and not the actual > executing qthread and this is bad. > No they will not. They will act just like they've been sent from the thread that does the emit. If you see some code where people tell they have to specify the queued > connection manually, it smell like a QThread have been inherited to inline > the run and they "fixed" the problem. I do a lot of Threading inside my > application and I never inherit it and never had any problems with my > thread either. > You don't need to use Qt::QueuedConnection when inheriting QThread and emitting from QThread::run, and I've done that aplenty. There's no problem with it, as long as you realize the QThread object is in the thread that created it - i.e. its internal data is not owned by QThread::run. With auto connection Qt will do the right thing and queue the slot call if the receiving thread is different from QThread::run (which it really almost always is) and to be really explicit this determination whether to queue, or to call directly is done at the time of emit (more concretely in QMetaObject::activate and its friends) and not at time of making the connections. Running imperative code in a subclassed thread is perfectly fine. Not every thread needs an event loop.
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
