19

I want to emit a signal from a C++ thread (std::thread) in Qt.

How can I do it?

Marco A.
  • 43,032
  • 26
  • 132
  • 246
Mohammad Reza Ramezani
  • 732
  • 3
  • 9
  • 22

4 Answers4

15

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.

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 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.

uchar
  • 2,552
  • 4
  • 29
  • 50
jpo38
  • 20,821
  • 10
  • 70
  • 151
  • *"I think QLabel::setText must be executed from QLabel's owner thread (most likely main thread)"* - more than most likely...all widgets must live on the main (QApplication) thread. P.S. [no need to sign posts on SO](http://meta.stackexchange.com/questions/2950/should-hi-thanks-taglines-and-salutations-be-removed-from-posts)! – HostileFork says dont trust SE Jul 27 '14 at 15:50
  • Not all...I think QCheckBox::setChecked works from thread (Or maybe it was QWidget::setVisible or QWidget::setEnabled....but I remember calling on of those with no problem from threads). But you are right, in general purpose, all GUI must be updated from main thread.... – jpo38 Jul 27 '14 at 16:04
  • Some things may wind up *seeming* to work, because the platform you're on is allowing it, or it just hasn't crashed yet. You may or may not be getting a warning in the debug output you're not seeing. But the contract w/Qt you're supposed to be obeying is to use signals/slots to communicate with widgets if you are on a non-GUI thread. [*"...the GUI classes, notably QWidget and all its subclasses, are not reentrant. They can only be used from the main thread."*](http://qt-project.org/forums/viewthread/29030) – HostileFork says dont trust SE Jul 27 '14 at 16:11
4

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)

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Thanks for your response. what about windows? – Mohammad Reza Ramezani Jul 27 '14 at 15:23
  • I don't know anything about Windows (never coded for it, and my first program was on punched cards in 1974). If you can get some equivalent of pipe, (or else make a socket), you could try. But as [Joachim Pileburg](http://stackoverflow.com/users/440558/joachim-pileborg) commented, you should go the Qt way and have a QThread. – Basile Starynkevitch Jul 27 '14 at 15:25
  • 5
    You *can* emit signals from any thread, even not created/managed by Qt through QThread. In order to handle a queued invocation instead the thread must be a QThread / have an event loop spinning. – peppe Jul 27 '14 at 15:43
1

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#invokeMethod

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.

Kamil Klimek
  • 12,884
  • 2
  • 43
  • 58
0
class MainForm : public QMainWindow
{
    Q_OBJECT

public:
    explicit MainForm(QWidget *parent = nullptr);
    virtual ~MainForm();

private:
signals:
    void signalSendButtonEnable(bool);

private slots:
    void singalReceiveButtonEnable(bool);


};


MainForm::MainForm(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainForm), status_{false}, io_context_{}, timer_{io_context_}
{
    ui->setupUi(this);

    // bind SIGNAL & SLOT
    connect(this, SIGNAL(signalSendButtonEnable(bool)), this, SLOT(singalReceiveButtonEnable(bool)));
}

MainForm::~MainForm()
{
    delete ui;
}

void MainForm::singalReceiveButtonEnable(bool status){  //recv signal
    qDebug() << "singalReceiveButtonEnable";
    this->ui->btnConnect->setEnabled(status);
}


void MainForm::start(){
    std::thread t([](){
        sleep(20);
        emit signalSendButtonEnable(true);   //send signal
    });
    t.detach();
}
Khan Lau
  • 91
  • 1
  • 3