Как правильно реализовать QThread... (пример, пожалуйста...)
В документации Qt для QThread сказано, что нужно создать класс из QThread и реализовать метод run.
Ниже взято из документации 4.7 Qthread...
Чтобы создать свои собственные потоки, создайте подкласс QThread и переопределите run(). Например:
class MyThread : public QThread
{
public:
void run();
};
void MyThread::run()
{
QTcpSocket socket;
// connect QTcpSocket's signals somewhere meaningful
...
socket.connectToHost(hostName, portNumber);
exec();
}
Таким образом, в каждом созданном мною потоке я делал именно это, и для большинства вещей он работает просто отлично (я не реализую moveToThread(this) ни в одном из моих объектов, и он прекрасно работает).
На прошлой неделе я наткнулся на препятствие (мне удалось разобраться, где я создавал свои объекты) и нашел следующее сообщение в блоге. Здесь в основном говорится, что создание подклассов QThread действительно не является правильным способом сделать это (и что документация неверна).
Это исходит от разработчика Qt, поэтому на первый взгляд я заинтересовался и, подумав дальше, согласен с ним. Следуя принципам ОО, вам действительно нужно только создать подкласс класса для дальнейшего улучшения этого класса... не просто использовать методы классов напрямую... вот почему вы создаете экземпляр...
Допустим, я хотел переместить пользовательский класс QObject в поток... каков был бы "правильный" способ сделать это? В этом сообщении в блоге он "говорит", что у него есть пример где-то... но если бы кто-то мог мне это объяснить, это было бы очень признательно!
Обновить:
Поскольку этому вопросу уделяется так много внимания, вот копия и вставка документации 4.8 с "правильным" способом реализации QThread.
class Worker : public QObject
{
Q_OBJECT
QThread workerThread;
public slots:
void doWork(const QString ¶meter) {
// ...
emit resultReady(result);
}
signals:
void resultReady(const QString &result);
};
class Controller : public QObject
{
Q_OBJECT
QThread workerThread;
public:
Controller() {
Worker *worker = new Worker;
worker->moveToThread(&workerThread);
connect(workerThread, SIGNAL(finished()), worker, SLOT(deleteLater()));
connect(this, SIGNAL(operate(QString)), worker, SLOT(doWork(QString)));
connect(worker, SIGNAL(resultReady(QString)), this, SLOT(handleResults(QString)));
workerThread.start();
}
~Controller() {
workerThread.quit();
workerThread.wait();
}
public slots:
void handleResults(const QString &);
signals:
void operate(const QString &);
};
Я все еще считаю, что стоит отметить, что они включают в себя Worker::workerThread член, который не нужен и никогда не используется в их примере. Удалите этот кусок, и это хороший пример того, как выполнять потоки в Qt.
4 ответа
Единственное, что я могу добавить, - это заявить, что QObjects имеют сходство с одной нитью. Обычно это поток, который создает QObject, Так что если вы создаете QObject в главном потоке приложения и хотите использовать его в другом потоке, вам нужно использовать moveToThread() изменить родство.
Это избавляет от необходимости подкласса QThread и создание ваших объектов в run() метод, таким образом, держа ваши вещи красиво инкапсулированы.
Этот пост в блоге содержит ссылку на пример. Это довольно короткий, но он показывает основную идею. Создайте свой QObjects, соедините ваши сигналы, создайте свой QThreadпереместите QObjects к QThread и начать поток. Механизмы сигнал / слот обеспечат правильное и безопасное пересечение границ потоков.
Возможно, вам придется ввести синхронизацию, если вам нужно вызывать методы для вашего объекта вне этого механизма.
Я знаю, что у Qt есть и другие приятные средства работы с потоками, помимо потоков, с которыми, вероятно, стоит познакомиться, но я еще не сделал этого:)
Вот один пример того, как правильно использовать QThread, но у него есть некоторые проблемы, которые отражены в комментариях. В частности, поскольку порядок выполнения слотов строго не определен, это может привести к различным проблемам. Комментарий, опубликованный 6 августа 2013 года, дает хорошее представление о том, как бороться с этой проблемой. Я использую что-то подобное в моей программе, и вот несколько примеров кода для пояснения.
Основная идея та же: я создаю экземпляр QThread, который живет в моем основном потоке, экземпляр рабочего класса, который живет в новом созданном мной потоке, и затем я подключаю все сигналы.
void ChildProcesses::start()
{
QThread *childrenWatcherThread = new QThread();
ChildrenWatcher *childrenWatcher = new ChildrenWatcher();
childrenWatcher->moveToThread(childrenWatcherThread);
// These three signals carry the "outcome" of the worker job.
connect(childrenWatcher, SIGNAL(exited(int, int)),
SLOT(onChildExited(int, int)));
connect(childrenWatcher, SIGNAL(signalled(int, int)),
SLOT(onChildSignalled(int, int)));
connect(childrenWatcher, SIGNAL(stateChanged(int)),
SLOT(onChildStateChanged(int)));
// Make the watcher watch when the thread starts:
connect(childrenWatcherThread, SIGNAL(started()),
childrenWatcher, SLOT(watch()));
// Make the watcher set its 'stop' flag when we're done.
// This is performed while the watch() method is still running,
// so we need to execute it concurrently from this thread,
// hence the Qt::DirectConnection. The stop() method is thread-safe
// (uses a mutex to set the flag).
connect(this, SIGNAL(stopped()),
childrenWatcher, SLOT(stop()), Qt::DirectConnection);
// Make the thread quit when the watcher self-destructs:
connect(childrenWatcher, SIGNAL(destroyed()),
childrenWatcherThread, SLOT(quit()));
// Make the thread self-destruct when it finishes,
// or rather, make the main thread delete it:
connect(childrenWatcherThread, SIGNAL(finished()),
childrenWatcherThread, SLOT(deleteLater()));
childrenWatcherThread->start();
}
Немного предыстории:
Класс ChildProcesses - это дочерний менеджер процессов, который запускает новые дочерние процессы с помощью вызовов spawn (), хранит список запущенных процессов и т. Д. Тем не менее, он должен отслеживать дочерние состояния, что означает использование waitpid () в Linux или WaitForMultipleObjects в Windows. Раньше я вызывал их в неблокирующем режиме, используя таймер, но теперь я хочу более быстрой реакции, что означает режим блокировки. Вот где приходит нить.
Класс ChildrenWatcher определяется следующим образом:
class ChildrenWatcher: public QObject {
Q_OBJECT
private:
QMutex mutex;
bool stopped;
bool isStopped();
public:
ChildrenWatcher();
public slots:
/// This is the method which runs in the thread.
void watch();
/// Sets the stop flag.
void stop();
signals:
/// A child process exited normally.
void exited(int ospid, int code);
/// A child process crashed (Unix only).
void signalled(int ospid, int signal);
/// Something happened to a child (Unix only).
void stateChanged(int ospid);
};
Вот как это работает. Когда все это запускается, вызывается метод ChildProcess::start() (см. Выше). Он создает новый QThread и новый ChildrenWatcher, который затем перемещается в новый поток. Затем я подключаю три сигнала, которые информируют моего менеджера о судьбе его дочерних процессов (выход / сигнал / бог знает, что случилось). Затем начинается главное веселье.
Я подключаю QThread::start () к методу ChildrenWatcher::watch(), чтобы он запускался, как только поток готов. Поскольку наблюдатель живет в новом потоке, здесь выполняется метод watch () (соединение с очередями используется для вызова слота).
Затем я подключаю сигнал ChildProcesses::stop () к слоту ChildrenWatcher::stop(), используя Qt::DirectConnection, потому что мне нужно сделать это асинхронно. Это необходимо, чтобы мой поток останавливался, когда диспетчер ChildProcesses больше не нужен. Метод stop () выглядит следующим образом:
void ChildrenWatcher::stop()
{
mutex.lock();
stopped = true;
mutex.unlock();
}
А потом ChildrenWatcher::watch():
void ChildrenWatcher::watch()
{
while (!isStopped()) {
// Blocking waitpid() call here.
// Maybe emit one of the three informational signals here too.
}
// Self-destruct now!
deleteLater();
}
Да, и метод isStopped() - это просто удобный способ использовать мьютекс в условии while ():
bool ChildrenWatcher::isStopped()
{
bool stopped;
mutex.lock();
stopped = this->stopped;
mutex.unlock();
return stopped;
}
Итак, что здесь происходит, так это то, что я устанавливаю флаг останова, когда мне нужно закончить, а затем при следующем вызове isStopped() он возвращает false и поток заканчивается.
Так что же происходит, когда цикл watch () заканчивается? Он вызывает deleteLater(), поэтому объект самоуничтожается, как только управление возвращается в цикл событий потока, который происходит сразу после вызова deleteLater() (когда возвращается watch ()). Возвращаясь к ChildProcesses::start(), вы можете видеть, что существует связь от сигнала destroy () наблюдателя к слоту quit () потока. Это означает, что поток автоматически завершает работу, когда завершает работу наблюдатель. И когда он закончен, он также самоуничтожается, потому что его собственный сигнал finish () подключен к его слоту deleteLater().
Это почти та же идея, что и в Maya, но поскольку я использую идиому самоуничтожения, мне не нужно зависеть от последовательности, в которой вызываются слоты. Сначала он всегда самоуничтожается, потом останавливается, потом тоже самоуничтожается. Я мог бы определить сигнал done () в работнике, а затем подключить его к своему собственному deleteLater(), но это означало бы только одно соединение больше. Поскольку для каких-либо других целей мне не нужен сигнал finish (), я решил просто вызвать deleteLater() из самого работника.
Maya также упоминает, что вы не должны размещать новые объекты QObject в конструкторе работника, потому что они не будут жить в потоке, в который вы перемещаете работника. Я бы сказал, в любом случае, сделайте это, потому что так работает ООП. Просто убедитесь, что все эти объекты QObject являются потомками работника (то есть используйте конструктор QObject(QObject*)) - moveToThread() перемещает все дочерние объекты вместе с перемещаемым объектом. Если вам действительно нужно иметь объекты QObject, которые не являются дочерними для вашего объекта, то переопределите moveToThread () в вашем работнике, чтобы он также перемещал все необходимые вещи.
Наследование класса qthread все равно будет запускать код в исходном потоке. Я хотел запустить слушатель udp в приложении, которое уже использует поток GUI (основной поток), и в то время как мой слушатель udp работал отлично, мой графический интерфейс был заморожен, так как он был заблокирован обработчиками событий подкласса qthread. Я думаю, что опубликованная g19fanatic правильная информация, но вам также понадобится рабочий поток, чтобы успешно перенести объект в новый поток. Я нашел этот пост, в котором подробно описывается, что можно и чего нельзя делать в QT.
Необходимо прочитать, прежде чем вы решите подкласс QThread!
Не отвлекайте от превосходного ответа @sergey-tachenov, но в Qt5 вы можете перестать использовать SIGNAL и SLOT, упростить ваш код и получить преимущество проверки времени компиляции:
void ChildProcesses::start()
{
QThread *childrenWatcherThread = new QThread();
ChildrenWatcher *childrenWatcher = new ChildrenWatcher();
childrenWatcher->moveToThread(childrenWatcherThread);
// These three signals carry the "outcome" of the worker job.
connect(childrenWatcher, ChildrenWatcher::exited,
ChildProcesses::onChildExited);
connect(childrenWatcher, ChildrenWatcher::signalled,
ChildProcesses::onChildSignalled);
connect(childrenWatcher, ChildrenWatcher::stateChanged,
ChildProcesses::onChildStateChanged);
// Make the watcher watch when the thread starts:
connect(childrenWatcherThread, QThread::started,
childrenWatcher, ChildrenWatcher::watch);
// Make the watcher set its 'stop' flag when we're done.
// This is performed while the watch() method is still running,
// so we need to execute it concurrently from this thread,
// hence the Qt::DirectConnection. The stop() method is thread-safe
// (uses a mutex to set the flag).
connect(this, ChildProcesses::stopped,
childrenWatcher, ChildrenWatcher::stop, Qt::DirectConnection);
// Make the thread quit when the watcher self-destructs:
connect(childrenWatcher, ChildrenWatcher::destroyed,
childrenWatcherThread, QThread::quit);
// Make the thread self-destruct when it finishes,
// or rather, make the main thread delete it:
connect(childrenWatcherThread, QThread::finished,
childrenWatcherThread, QThread::deleteLater);
childrenWatcherThread->start();
}
Моя версия передовой модели потока в Qt5 так просто:worker.h:
/*
* This is a simple, safe and best-practice way to demonstrate how to use threads in Qt5.
* Copyright (C) 2019 Iman Ahmadvand
*
* This is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* It is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#ifndef _WORKER_H
#define _WORKER_H
#include <QtCore/qobject.h>
#include <QtCore/qbytearray.h>
#include <QtCore/qthread.h>
#include <QtGui/qevent.h>
namespace concurrent {
class EventPrivate;
class Event : public QEvent {
public:
enum {
EventType1 = User + 1
};
explicit Event(QEvent::Type);
Event(QEvent::Type, const QByteArray&);
void setData(const QByteArray&);
QByteArray data() const;
protected:
EventPrivate* d;
};
class WorkerPrivate;
/* A worker class to manage one-call and permanent tasks using QThread object */
class Worker : public QObject {
Q_OBJECT
public:
Worker(QThread*);
~Worker();
protected slots:
virtual void init();
protected:
bool event(QEvent*) override;
protected:
WorkerPrivate* d;
signals:
/* this signals is used for one call type worker */
void finished(bool success);
};
} // namespace concurrent
#endif // !_WORKER_H
worker.cpp:
/*
* This is a simple, safe and best-practice way to demonstrate how to use threads in Qt5.
* Copyright (C) 2019 Iman Ahmadvand
*
* This is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* It is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include "worker.h"
using namespace concurrent;
class concurrent::EventPrivate {
public:
QByteArray data;
};
Event::Event(QEvent::Type t):QEvent(t), d(new EventPrivate) {
setAccepted(false);
}
Event::Event(QEvent::Type t, const QByteArray& __data) : Event(t) {
setData(__data);
}
void Event::setData(const QByteArray& __data) {
d->data = __data;
}
QByteArray Event::data() const {
return d->data;
}
class concurrent::WorkerPrivate {
public:
WorkerPrivate() {
}
};
Worker::Worker(QThread* __thread) :QObject(nullptr), d(new WorkerPrivate) {
moveToThread(__thread);
QObject::connect(__thread, &QThread::started, this, &Worker::init);
QObject::connect(this, &Worker::finished, __thread, &QThread::quit);
QObject::connect(__thread, &QThread::finished, __thread, &QThread::deleteLater);
QObject::connect(__thread, &QThread::finished, this, &Worker::deleteLater);
}
Worker::~Worker() {
/* do clean up if needed */
}
void Worker::init() {
/* this will called once for construction and initializing purpose */
}
bool Worker::event(QEvent* e) {
/* event handler */
if (e->type() == Event::EventType1) {
/* do some work with event's data and emit signals if needed */
auto ev = static_cast<Event*>(e);
ev->accept();
}
return QObject::event(e);
}
usage.cpp:
#include <QtCore/qcoreapplication.h>
#include "worker.h"
using namespace concurrent;
Worker* create(bool start) {
auto worker = new Worker(new QThread);
if (start)
worker->thread()->start();
return worker;
}
int main(int argc, char *argv[]) {
QCoreApplication app(argc, argv);
auto worker = create(true);
if (worker->thread()->isRunning()) {
auto ev = new Event(static_cast<QEvent::Type>(Event::EventType1));
qApp->postEvent(worker, ev, Qt::HighEventPriority);
}
return app.exec();
}