Как работать с QSerialPort в потоке ?

Как это пофиксить правильно.

https://lmgtfy.com/?q=Cannot+create+children+for+a+parent+that+is+in+a+different+thread.

Ну у меня вопрос то был, почему в моем случае прога работает и потом падает, она не падает прям сразу на первом обращении к порту. Именно это я нигде не нагуглил на этот вопрос ответ.

код где?

Код взят отсюда http://www.cyberforum.ru/qt/thread1509751.html

Можно вот так попробовать:

public slots:
    void process(int param)
    {
        if (thread() != QThread::currentThread())
        {
            QMetaObject::invokeMethod(this, "process", Qt::QueuedConnection,
                                      Q_ARG(int, param));
            return;
        }

        qDebug() << "param =" << param;
    }

Если текущий поток это не тот поток, которому принадлежит объект, то вызвать этот же слот через очередь. Метод будет работать асинхронно относительно вызывающей стороны.

Но вообще надо делать так, чтобы твой код кидал сигналы, которые соединены со слотами объекта из другого потока. Соединение должно быть через очередь, тогда слот будет вызван в родном потоке и магия заработает.

Проблема в том, что через сигналы если, то усложняется код. Я хочу сначала вызвать слот открытия порта и если успешно, то вызвать метод посылки запроса. Но если у меня сигнал на открытие порта, то получается из того класса результат в вызывающий класс кидать ответным сигналом ?

Переноси логику внутрь класса. А наружу будет торчать высокоуровневый интерфейс. Зачем ты выносишь код в отдельный поток, если там только тупая работа с классом QSerialPort?

Мне нужно по результатам от порта обновлять gui содержимое формы проги. Я засунул логику обновления gui в тот же класс, который с портом работает. Правильно ли я понял, что надо логику с gui засунуть в отдельный класс и туда сигналами из класса порта ходить.

Зачем ты вынес QSerialPort в отдельный поток? Я с ним не работал, он что тормозит и надолго блокирует поток? Если нет, то я бы не стал заморачиваться со вторым потоком. Только лишняя писанина.

Если использовать его как блокирующий без сигнала ReadyRead, то будет тормозить как правило. Я заметил, что почти без тормозов, если читать через connect сигнала readyread.

Ну раз тормозит, то делай отдельный поток. Что уж поделать. С GUI работать можно строго только из главного потока. Поэтому в основном потоке держи код, который обрабатывает пользовательский ввод и даёт команды через сигналы в класс порта. Класс порта в своём потоке выполняет работу и отчитывается главному потоку через сигнал. Это в общем.

Посмотрел код на киберфоруме, а там thisPort.deleteLater();. Объект со стека так не надо удалять. Ты аккуратнее с тем кодом. Там много говнеца.

Кстати как правильно грохать при закрытии qthread, делаю quit в деструкторе, но бывает падает на закрытии.

Сначала вызываешь quit, потом wait. В wait можно передать сколько нужно ждать. После этого можно делать delete на объект QThread, если он у тебя в куче, а не на стеке.

Я объявлял через указатель, это вроде на стеке имелось ввиду ? Когда делал просто без указателя, не удавалось нормально закрыть прогу.

Если создаёшь через new, то это куча. Стек это когда QThread thread;

А вот как грохать, если создал так QThread thread; Брал стандартный пример из документации qt, они там делают через указатель, а я сделал без и не работало. И как его сделать без указателя нормальное завершение у меня так и не вышло.

Так же. Сначала quit, потом wait. Только не нужно делать delete. И да, эти методы нужно вызывать из другого потока.

Перемести в свой поток. Либо создай через указатель в своем потоке, когда тот уже запущен. Смотри moveToThread(). Методы вызывай через слоты подключенные через QueuedConnection.

Ты в своей трудовой деятельности решаешь проблемы этого рода так же как в первых строках этой выдачи? (пока не читал, просто интересно).

но отладчик ее не ловит нормально и просто закрывает прогу.

Под виндой что ле?

Я вообще не использую поток для QSerialPort, ибо он уже и так ассинхронный.

Я вообще не использую поток для QSerialPort, ибо он уже и так ассинхронный.

Это да, но там есть особенность в виндах, что при использовании GUI приложения при клике мышой и ее удержании на заголовке окна (или при перетаскивании окна, или его ресайзе), евент луп останавливается и сериал порт может просрать данные (переполнение FIFO к примеру).

Поэтому, народ, в любом случае, суйте в поток через moveToThread().

ЗЫ: Такие вот дела... Просто напоминалка чтоб в будущем не было нытья. :)

Хм, не знал. Я так понимаю поэтому у меня и QML зависает при ресайзе.

Ну да, ассинхронность и многопоточность, так то одна фигня, согласен.

Это под любой системой плата за разделение цикла обработки событий между кучей ничего не знающих про друг друга сущностей. Запусти пару тысяч таймеров в ui треде с разрешением кванта cpu и получишь сходный эффект.

Прикопаться к столбу - бесценно.

Не, неверно. Это только виндовая «фича» такая.

Это не только к QSP относится, даже QTimer останавливается:

#include "dialog.h"
#include "ui_dialog.h"

#include <QTimer>
#include <QDateTime>
#include <QDebug>

Dialog::Dialog(QWidget *parent) :
    QDialog(parent)
{
    const auto t = new QTimer(this);
    connect(t, &QTimer::timeout, [this]() {
        qDebug() << QDateTime::currentDateTime();
    });
    t->start(1000);
}

Если кликнуть правой клавишей мыши на заголовке окна и держать.

Так что надо всЁ через moveToThread() мувить, чтобы не обделаться. :)

PS: То-ли это винда кривая, то-ли касяк в Qt event loop.

То-ли это винда кривая, то-ли касяк в Qt event loop

Порядок работы с портом в оффтопе и в онтопике - немножечко различаются

Я вообще не использую поток для QSerialPort, ибо он уже и так ассинхронный

+1, я даже для QTcpSocket не юзаю поток, если обмен не очень мощный. А тут какой-то жалкий порт максимум мегабит

QSerialPort надо создавать в потоке из которого потом ведется работа с ним.