Motivation for multithreading in my App
-
Thank you both for your help!
@JonB :
I think I want to go with @MrShawn 's solution (not subclassing QThread, but rather moving MyModule to a QThread withmoveToThread()
), and in that solution I don't have theQThread::run()
available in myMyModule
(I have to subclass QThread to inheritQThread::run()
...)@MrShawn
From your code sample I can see that invokingmoduleThread->start()
will send a SIGNAL toMyModule::start()
, but what shouldMyModule::start()
do in order to be kept alive?@Absurd
I didn't say anything about sub-classing! You would only need to do that if you needed to replace/change the behaviour ofQThread::start/run/exec()
, which you do not, since the default behaviour already suits you.@MrShawn
From your code sample I can see that invoking moduleThread->start() will send a SIGNAL to MyModule::start(), but what should MyModule::start() do in order to be kept alive?QThread moduleThread; //event loop in another thread ... moduleThread->start();
That's exactly as I said. I suggested you look at the
QThread
reference links I posted. You would see thatQThread::start()
callsQThread::run()
callsQThread::exec()
by default, unless you do something else about it. It's theQThread::exec()
that is providing the event loop/keep alive which I think you are struggling with.I don't know, maybe if you read carefully through the really simple usage in https://wiki.qt.io/QThreads_general_usage, which is the same as @MrShawn's, the explanation would help.
P.S.
I wonder if you're thinkingmyModule->moveToThread(&moduleThread);
"replaces" theQThread
. It does not, it just moves your module into the thread (its variables/slots/where it runs).QObject::connect(&moduleThread,&QThread::started,myModule,&MyModule::start); //start may be your function that instantiates some other objects within your module.
This is just going to call your slot via a signal when the thread starts, for you to do your own initializations, at the end of which your slot should simply return not call something else. It will still be going
QThread::start()
->QThread::run()
->QThread::exec()
.MyModule::start
has nothing to do withQThread::start
. Try renaming toMyModule::myStart
and goingQObject::connect(&moduleThread,&QThread::started,myModule,&MyModule::myStart);
and it will work just the same. Does that clarify for you? -
Ok, this is how I transformed my code:
In main.cpp:
int main(int argc, char* argv[]) { Controller controller(argc, argv); return controller.runApplication(); }
And in Controller:
Controller::Controller(int argc, char* argv[]) : _app(argc, argv) { // does nothing } void Controller::initModule() { _devicesManager = new DevicesManager; _moduleThread = new QThread(this); // Controller will be the parent of QThread - and will be responsible for deleting it _devicesManager->moveToThread(_moduleThread); _moduleThread->start(); } void Controller::initView() { _gui = new GUI; } int Controller::runView() { _gui->show(); return _app.exec(); } void Controller::connectSignals() { connect(_moduleThread, SIGNAL(started()), _devicesManager, SLOT(start())); // more to come, for now just connecting QThread's 'started' signal to DevicesManager::start() } int Controller::runApplication() { initModule(); initView(); connectSignals(); return runView(); }
For now,
DeviceManager
does absolutely nothing, except this:void DevicesManager::start() { qDebug() << "Starting!"; }
(that's why I didn't bother to connect
QThread::finished
toDeviceManager::deleteLater
for now - because it holds no memory allocation)But I am experiencing two problems:
- When I run it, the GUI runs fine, but then when I close the GUI by clicking the x button of the window, I get:
QThread: Destroyed while thread is still running - I don't see the "Starting!" printed out to the console, which makes me think that start didn't really run, not to mention running on a different thread...
- When I run it, the GUI runs fine, but then when I close the GUI by clicking the x button of the window, I get:
-
Ok, this is how I transformed my code:
In main.cpp:
int main(int argc, char* argv[]) { Controller controller(argc, argv); return controller.runApplication(); }
And in Controller:
Controller::Controller(int argc, char* argv[]) : _app(argc, argv) { // does nothing } void Controller::initModule() { _devicesManager = new DevicesManager; _moduleThread = new QThread(this); // Controller will be the parent of QThread - and will be responsible for deleting it _devicesManager->moveToThread(_moduleThread); _moduleThread->start(); } void Controller::initView() { _gui = new GUI; } int Controller::runView() { _gui->show(); return _app.exec(); } void Controller::connectSignals() { connect(_moduleThread, SIGNAL(started()), _devicesManager, SLOT(start())); // more to come, for now just connecting QThread's 'started' signal to DevicesManager::start() } int Controller::runApplication() { initModule(); initView(); connectSignals(); return runView(); }
For now,
DeviceManager
does absolutely nothing, except this:void DevicesManager::start() { qDebug() << "Starting!"; }
(that's why I didn't bother to connect
QThread::finished
toDeviceManager::deleteLater
for now - because it holds no memory allocation)But I am experiencing two problems:
- When I run it, the GUI runs fine, but then when I close the GUI by clicking the x button of the window, I get:
QThread: Destroyed while thread is still running - I don't see the "Starting!" printed out to the console, which makes me think that start didn't really run, not to mention running on a different thread...
- When I run it, the GUI runs fine, but then when I close the GUI by clicking the x button of the window, I get:
-
hi, @Absurd
you start your QThread object before you do the connection -> started signal is emitted before the connection is made -> slot gets not invoked.
_moduleThread->start();
-
@J.Hilk ohh... how silly of me... :
Thank you.Do you know what could be the cause for the second thing?
QThread: Destroyed while thread is still running@Absurd said in Motivation for multithreading in my App:
@J.Hilk ohh... how silly of me... :
Thank you.Do you know what could be the cause for the second thing?
QThread: Destroyed while thread is still runningCall
QThread::quit
and after thatQThread::wait
before you exit the application.Addendum:
What is a good justification to use threads anyway?
Latency. Having a slow, blocking or otherwise high latency operation you don't need or want to wait for - you need to thread it, otherwise you do not.
-
@Absurd said in Motivation for multithreading in my App:
@J.Hilk ohh... how silly of me... :
Thank you.Do you know what could be the cause for the second thing?
QThread: Destroyed while thread is still runningCall
QThread::quit
and after thatQThread::wait
before you exit the application.Addendum:
What is a good justification to use threads anyway?
Latency. Having a slow, blocking or otherwise high latency operation you don't need or want to wait for - you need to thread it, otherwise you do not.
@kshegunov thanks for your reply. appreciate it.
@kshegunov said in Motivation for multithreading in my App:
Call QThread::quit and after that QThread::wait before you exit the application.
I should call
QThread::quit
&QThread::wait
fromController
's destructor, right? -
@kshegunov thanks for your reply. appreciate it.
@kshegunov said in Motivation for multithreading in my App:
Call QThread::quit and after that QThread::wait before you exit the application.
I should call
QThread::quit
&QThread::wait
fromController
's destructor, right?@Absurd said in Motivation for multithreading in my App:
I should call QThread::quit & QThread::wait from Controller's destructor, right?
Yes, that is correct. You should also free your worker objects:
QObject::connect(_moduleThread, &QThread::finished, _devicesManager, &QObject::deleteLater);
-
@Absurd said in Motivation for multithreading in my App:
I should call QThread::quit & QThread::wait from Controller's destructor, right?
Yes, that is correct. You should also free your worker objects:
QObject::connect(_moduleThread, &QThread::finished, _devicesManager, &QObject::deleteLater);
@kshegunov why not just
delete _deviceManager
afterQthread::wait()
has returned?@MrShawn said:
No, the first QString is like a "key" for your message type, so that you know what keys to look for or are available in your QVariantMap.
Can you please give a usage example for that?
I couldn't figure out why isn'tvoid message(QString, QVariant)
enough... -
@kshegunov why not just
delete _deviceManager
afterQthread::wait()
has returned?@MrShawn said:
No, the first QString is like a "key" for your message type, so that you know what keys to look for or are available in your QVariantMap.
Can you please give a usage example for that?
I couldn't figure out why isn'tvoid message(QString, QVariant)
enough...@Absurd said in Motivation for multithreading in my App:
@kshegunov why not just
delete _deviceManager
afterQthread::wait()
has returned?It's possible, but it still belongs to the worker thread, you may get warnings.
-
@kshegunov why not just
delete _deviceManager
afterQthread::wait()
has returned?@MrShawn said:
No, the first QString is like a "key" for your message type, so that you know what keys to look for or are available in your QVariantMap.
Can you please give a usage example for that?
I couldn't figure out why isn'tvoid message(QString, QVariant)
enough...void message(QString msgType, QVariantMap data);
QVariantMap not QVariant.
QVarantMap is a map with QStrings for keys, so like say you emit a signal that is declared like above, it may look something like this.
QVariantMap params; int param1 = 2; double param2 = 2.2; params.insert("param1",param1); params.insert("param2",param2); emit message("runSomeSpecificMethod",params);
Then the receiving slot may look something like this
void getMessage(QString messageType, QVariantMap data) { if (messageType.compare("runSomeSpecificMethod",Qt::CaseInsensitive) == 0){ SomeSpecificMethod(data.value("param1").toInt(),data.value("param2").toDouble()); } }