You probably should not emit a Qt signal from a std::thread-created thread in general without care. See Jpo38's answer : connection type matters, etc...
If the thread is running some Qt event loop, you probably could. See threads and QObject
There is a (Unix-specific probably) work-around, doing the same as for Unix signals with Qt : use a pipe from your std::thread to the main thread.
But, as commented by Joachim Pileborg, you should make your own QThread. It is the simplest, and probably the shortest (in term of source code), and you just need to copy and paste some existing example and adapt it to your need.
Beware that AFAIK only the main thread should do Qt GUI manipulations. You should not use any QWidget (etc...) outside of the main thread! (BTW, GTK has the same restriction, at least on Linux: only the main thread is supposed to use the X Windows system protocols)
You definitely can emit a signal from a thread (QThread, std::thread or even boost::thread). Only you must be careful of your connect function's fifth parameter (Qt::ConnectionType):
If Qt::DirectConnection: The slot is invoked immediately (from the current thread), when the signal is emitted.
If Qt::QueuedConnection: The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.
The problem is not really from which thread you emit the signal, it's more from which thread the slot is being invoked. For instance, I think QLabel::setText must be executed from QLabel's owner thread (most likely main thread). So if you emit a signal connected to a QLabel's setText from a thread, connection must be done with Qt::AutoConnection, Qt::QueuedConnection or Qt::BlockingQueuedConnection.
Probably you will have to use Qt::QueuedConnection so your signal will be invoked at proper thread (not your std::thread). Remember that your signal won't be invoked immedietly.
You probably should not emit a Qt signal from a
std::thread
-created thread in general without care. See Jpo38's answer : connection type matters, etc...If the thread is running some Qt event loop, you probably could. See threads and QObject
There is a (Unix-specific probably) work-around, doing the same as for Unix signals with Qt : use a pipe from your
std::thread
to the main thread.But, as commented by Joachim Pileborg, you should make your own QThread. It is the simplest, and probably the shortest (in term of source code), and you just need to copy and paste some existing example and adapt it to your need.
Beware that AFAIK only the main thread should do Qt GUI manipulations. You should not use any QWidget (etc...) outside of the main thread! (BTW, GTK has the same restriction, at least on Linux: only the main thread is supposed to use the X Windows system protocols)
You definitely can emit a signal from a thread (
QThread
,std::thread
or evenboost::thread
). Only you must be careful of your connect function's fifth parameter (Qt::ConnectionType
):If
Qt::DirectConnection
: The slot is invoked immediately (from the current thread), when the signal is emitted. IfQt::QueuedConnection
: The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.See ConnectionType-enum for more options.
The problem is not really from which thread you emit the signal, it's more from which thread the slot is being invoked. For instance, I think
QLabel::setText
must be executed fromQLabel
's owner thread (most likely main thread). So if you emit a signal connected to aQLabel
'ssetText
from a thread, connection must be done withQt::AutoConnection
,Qt::QueuedConnection
orQt::BlockingQueuedConnection
.If you're keeping pointer to your QObject then you could use one of
QMetaObject::invokeMethod
member http://qt-project.org/doc/qt-5/qmetaobject.html#invokeMethodProbably you will have to use
Qt::QueuedConnection
so your signal will be invoked at proper thread (not your std::thread). Remember that your signal won't be invoked immedietly.