I have an application using a QSerialPort, the very last thing my program does is call my closePort function which looks like this:
//Closes the port when we're done with it
void SerialCommSession::closePort()
{
connected = false;
if(m_port.isOpen())
{
qDebug() << "closing port";
m_port.close();
}
}
Some amount of the time it works fine, and the program starts up again without any issue. But maybe 75% of the time, when I try to run the program again it fails to open the port, returning error code 2. How long should QSerialPort.close() take to execute? And how can I ensure it completes?
Make your closePort function a slot and connect it to QCoreApplication::aboutToQuit:
connect(qApp, &QCoreApplication::aboutToQuit, someCommSessionPointer, &SerialCommSession::closePort)
When the event loop exits and before the application quits, your slot will be invoked. Make sure you have included <QCoreApplication> or one of its derived classes in order for the qApp macro to work.
Also:
How long should QSerialPort.close() take to execute? And how can I ensure it completes?
Slots in the same thread are invoked synchronously, so it can take as long as it needs to before control returns to the application. The application won't quit until your slot returns.
Related
I have this code:
mainwindow.h:
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow {
private:
QMutex mutex;
}
mainwindow.cpp:
void MainWindow::on_calculateBtn_clicked() {
QMutexLocker locker(&mutex);
qDebug() << "mutex has been locked" << endl;
ui->calculateBtn->setEnabled(false);
startProcess(); // huge calcutations
ui->calculateBtn->setEnabled(true); // performed before startProcess() has finished (why?)
qDebug() << "mutex will be unlocked" << endl;
}
If I click calculateBtn again while startProcess() has not finished, my program crashed:
pure virtual method called
The program has unexpectedly finished.
I tried:
void MainWindow::on_calculateBtn_clicked() {
if (!processing) {
processing = true;
ui->calculateBtn->setEnabled(false);
startProcess();
ui->calculateBtn->setEnabled(true); // performed before startProcess() has finished (why?)
processing = false;
}
}
There is no shared data, I just want one startProcess() will not be started before other startProcess() finished.
Why did it happen? I think that mutex have to lock function startProcess() in on_calculateBtn_clicked() and nothing should happens. It seems I don't know any important things. Thanks in advance for any advice.
The same mutex is locked twice from the same thread (the main thread, which contains the event loop), which is invalid for a non-recursive mutex.
But even a recursive mutex will not solve the basic problem of your code; you need a flag to indicate that you are already doing the calculations, and return from all subsequent calls to your method while they are running, else you'll start them multiple times in the same thread, one interrupting the other, probably with bad results. Even better, disable the button while the method is running and take care it isn't called by other ways.
However, if calling startProcess() multiple times and run it simultaneously is intended, you'll have to start a thread for each button press and take care for access to shared data (using mutexes, most probably) - that's where the real fun begins.
I think that you (by default) have a Qt::DirectConnection with this button press, right? i.e.:
connect(..., SIGNAL(...),
..., SLOT(:on_calculateBtn_clicked()), <by-default-Qt::DirectConnection>);
The issue I see here is that the first button press will run the function void MainWindow::on_calculateBtn_clicked() immediately.... which is all good so far, the mutex is locked and huge calcs are running.
However when you press the button again, void MainWindow::on_calculateBtn_clicked() is again immediate run (like an interrupt). The first thing it does is try to lock the mutex and it must hang here.
If you make connection to the slot void MainWindow::on_calculateBtn_clicked() Qt::QueuedConnection then it won't trigger the button press until it has clear the other tasks on its task queue.
but.... weather or not your design here is good is questionable, I think over you should re-think your strategy (as some comments have suggested)
EDIT
Oh yeah, meant to add..... to answer your question, therefore I don't think the mutex is begin unlocked twice... its just the nature of the direct connection
I'm using QtConcurrent to do some heavy background image processing and I want to display the image while parts of it are being updated progressively.
Each line of the image is computed separately and is passed a functor.
To compute the full image I then have a sequence of item that I pass to QtConcurrent mapped and each line emits a signal when it is done computing
Here is the instantiation of the class Worker:
//living in the main(gui) thread !
Worker::Worker(VideoEngine* engine):_engine(engine){
_watcher = new QFutureWatcher<bool>;
_watcher->setPendingResultsLimit(200);
connect(_watcher, SIGNAL(resultReadyAt(int)), this, SLOT(onProgressUpdate(int)));
connect(_watcher, SIGNAL(finished()), engine, SLOT(engineLoop()));
}
Here is the slot to report progress:
void Worker::onProgressUpdate(int i){
if(i < (int)_rows.size() && i%10==0){
cout << " index = " << i << " y = "<< _rows[i] << endl;
_engine->checkAndDisplayProgress(_rows[i],i);
}
}
Now the usage:
void Worker::_computeTreeForFrame(.../*unrelevant args*/){
....
....
_watcher->setFuture(
QtConcurrent::mapped(_sequence,
boost::bind(&VideoEngine::metaEnginePerRow,_1,output)));
}
}
All the signals are emitted but the slot onProgressUpdate gets called only when Qtconcurrent::mapped is done with all the items in the sequence.
When executing it has a huge delay while the sequence is processing and then all slots are executed sequentially afterwards.
I have tried all types of signal/slots connection and none of them changed this behaviour.
Any clue ?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EDIT after Shf suggestion
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The call was made until now in the main(gui) thread.
I changed the call to :
_computeFrameWatcher->setFuture(QtConcurrent::run(_worker,&Worker::computeTreeForFrame));
Since _computeTreeForFrame is now executed in another thread, I changed the call to QtConcurrent::mapped to:
_watcher->setFuture(QtConcurrent::mapped(_sequence,
boost::bind(&VideoEngine::metaEnginePerRow,_1,output)));
_watcher->waitForFinished();
This results in exactly the same behaviour as before.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EDIT after Marek R suggestion
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ok so I made so tests and here is what I observed:
QtConcurrent::map :
Doesn't emit the signal resultReadyAt(int)
QtConcurrent::mapped
Emits resultReadyAt(int) only when finished
It doesn't matter if the call to the map function is done in a separate thread the same behaviour is encountered.
I also gave a try to the signal progressValueChanged(int) as the Qt progressDialog example suggests.
The signal progressValueChanged(int) gets emitted only for 2 lines in the image (the first and last).
This is really weird as in the Qt progress dialog example it is emitted smoothly.
I changed a bit the Qt example to launch the map function in another thread than the main thread and it still works well in that case.
The issue must arise from somewhere else.
Maybe the GUI event loop is doing something I don't expect ? I have no clue what.
I will now try QtConcurrent::mappedReduced and report with the results :-)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EDIT after giving a try to QtConcurrent::mappedReduced
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
It doesn't work and calls the "reduce" function ONLY when the "map" function is done. In other words it does the same than the previous signal/slots mechanism.
I'm running low in possibilities now
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EDIT I'm back to a solution as close as the Qt progress dialog example
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Something must be wrong if I can't get the same behaviour than the Qt example.
Here's the code now:
//created in the main thread! (gui)
Worker::Worker(VideoEngine* engine):_engine(engine),_watcher(0){
_watcher = new QFutureWatcher<void>;
_watcher->setPendingResultsLimit(200);
connect(_watcher,SIGNAL(progressValueChanged(int)), _engine,
SLOT(onProgressUpdate(int)));
connect(_watcher, SIGNAL(finished()), engine, SLOT(engineLoop()));
}
//executed on the main thread
void Worker::computeTreeForFrame(...){
...
_watcher->setFuture(QtConcurrent::map(_sequence,boost::bind(metaEnginePerRow,_1,output)));
...
}
The call to computeTreeForFrame...
...
_worker->computeTreeForFrame();
...
This call is done in a slot .
It emits the signals for the line 0 and for the last line as told before but doesn't emits anything else.
Shouldn't this do EXACTLY what the Qt example does?
From task description it looks like you should use mappedReduced. Problem is that I don't see a good way to get partial results. One way to overcome this problem is to emit signal form reduce function.
It is possible that this thread may help.
It seems, that QtConcurrent::mapped does not put VideoEngine::metaEnginePerRow in another thread, judging by the documentation. If image is processed in the same thread as GUI, then your slots indeed will be executed after processing, no matter what type of connection you select, just as you've described.
The solution is to either run Worker::_computeTreeForFrame (as i understood, your main processing function) in another thread via QtConcurrent::run or to put your Worker object in another thread probably via QObject::moveToThread(). Then, the connection type you should use is Qt::QueuedConnection (or if you will put Worker in another thread before connection, you can connect even with Qt::AutoConnectionor Qt::UniqueConnection, caller and receiver will be in a different threads, so qt will automaticly chose QueuedConnection`)
EDIT:
I'm not sure, but your _watcher = new QFutureWatcher<bool>; is still created in the main thread and if you call
_watcher->setFuture(QtConcurrent::mapped(_sequence,
boost::bind(&VideoEngine::metaEnginePerRow,_1,output)));
_watcher->waitForFinished();
would _watcher set GUI thread to wait, in what it was created or thread, where this command is executed. If _watcher->setFuture(QtConcurrent::mapped(_sequence,
boost::bind(&VideoEngine::metaEnginePerRow,_1,output))); if the end of a function, is _watcher->waitForFinished(); needed at all? Qt will destroy thread right after it's execution and you set your processing function to run, why wait?
And _computeFrameWatcher should be of QFuture<void*> type.
EDIT2:
Ok, before i give up, i suggest you to test QObject::moveToThread:
before you call _worker->computeTreeForFrame(); , put it in another thread:
QThread *workerThread=new QThread();
_worker->moveToThread();
_worker->computeTreeForFrame();
/* connect _worker's finished signal with workerThread::quit and deleteLater slots */
and all connections within _worker should be DirectConnection and all connections between _worker and main (GUI) thread should be connected with QueuedConnection. Also it's probably good to create new thread in _worker constructor and move it to another thread immediately, this way you can destroy thread in _worker's destructor and don't worry about thread problem's in GUI thread
I have a case where a signal is being lost and I don't understand why -- normally signals sent prior to the event loop starting just get queued up and sent then.
This is what the code looks like (for a QThread object):
void OffloadHandler::run()
{
cout << "Start" << endl;
connect( this, SIGNAL(loopStarted()), SLOT(onLoopStarted()), Qt::QueuedConnection );
emit loopStarted();
exec();
}
void OffloadHandler::onLoopStarted()
{
cout << "Here!" << endl;
}
The thread is started elsewhere and Start is written to the console but Here1 never is -- the signal is not received. I use the same pattern in my main message loop and it works, but in this threaded message loop it appears not to work.
Is there anything clearly wrong in my code here?
Your code is valid and it should run. Are you sure you have an event loop running in the thread that oh is created in?
Cause the emit loopStarted() should send an event to oh's event loop, which will be processed and will call onLoopStarted(). I've tested your code out, and it works for me.
Btw, It's generally recommended that you do not add slots to your QThread, and avoid using moveToThread( this );
Unfortunately, I don't really understand your use case, so I can't give a better solution. But here is some amazing documentation which has nice DOs and DONTs regarding QThreads.
Okay, I've figured it out, I've been bitten by the QThread ownership oddity. One has to be really careful when connecting to the QThread object itself since that Object is not owned by the thread by default.
So at the point where the thread is created I must move the thread to the thread:
OffloadHandler * oh = new OffloadHandler();
oh->moveToThread( oh ); //MOVE TO SELF!
oh->start();
Once I do this the signals work as expected.
I have an app with such structure: all the datatypes (class INode) are stored in plugins (DLLs). Some of the datatypes can be drawn (if they're IDrawable).
To load an object of, e.g. class PointCloudNode: public INode I have a special input plugin (DLL) which is called class PointCloudParser: public IIOPlugin and IIOPlugin is a thread with some specific functionality: class IIOPlugin: public QThread.
All the objects are created by NodeFactory class which is a singleton stored in separate DLL.
And here's the problem:
void PointCloudNode::update()
{
QObject::connect (this,SIGNAL(tmptmp()),this,SLOT(drawObject()));
emit tmptmp();
}
If I do this from any thread (main thread or the Input Plugin thread)
NodeFactory* fab = NodeFactory::getInstance();
boost::shared_ptr<INode> pc(fab->createNode("pointCloud","myPC"));
boost::shared_ptr<IDrawable> dr = boost::dynamic_pointer_cast<IDrawable>(pc);
dr->update();
The update launches, the tmptmp() signal is emitted, and the slot (drawObject()) executes correctly.
BUT
if do just the same, but create the object in my Input Plugin, pass over the shared pointer and execute dr->update() in another function, the slot drawObject() is never entered though all the code is executed (including connect, etc.).
To be more precise, here's the Input Plugin:
void PointCloudParserPlugin::doLoad(const QString& inputName, boost::shared_ptr<INode> container)
{
NodeFactory* factory = NodeFactory::getInstance();
boost::shared_ptr<INode> node = factory->createNode("pointCloud", inputName);
// here goes the loading itself, nothing special...
container->addChild(node); //that's the container where I keep all the objects
//boost::dynamic_pointer_cast<IDrawable>(container->getChild(inputName))->update();
//If I uncomment this line, it all works: the slot is launched.
emit loadingFinished(inputName); // it executes the following function
}
The last emit is connected to this:
void GeomBox::updateVisualization(const QString& fileName)
{
boost::shared_ptr<INode> node = container_->getChild(fileName);
boost::shared_ptr<IDrawable> nodeDrawable = boost::dynamic_pointer_cast<IDrawable>(node);
nodeDrawable->update(); //this is the problem line: update() executes, connect() works, but the slot never runs :(
}
How come? The node object is the same all the way through, it is valid. Every line in code in launched, QObject::connect doesn't write anything to debug window, the signal tmptmp() is emitted, but the slot drawObject() in one case is never reached? Any ideas?
Upd.: If I do not inherit IIOPlugin from QThread, everything works fine (i.e. load the object in the main thread). I expected the signals/slots to work across the threads...
Since you are sending a signal across to a different thread, you might need to explicitly tell Qt that the connection should be a queued one:
QObject::connect(this, SIGNAL(tmptmp()), this, SLOT(drawObject()), Qt::QueuedConnection );
By default Qt will use Qt::AutoConnection as that last parameter, and it will choose whether to use a direct connection (if the slot is in the same thread as the emitter) or a queued connection (if the slot is in a different thread). But since your thread is in a separate library, maybe Qt isn't making the right assumption here.
[related to this question]
I wrote this piece of code to understand how qt signals and slots work. I need someone to explain the behaviour, and to tell me if I'm right about my own conclusions.
My program:
connectionhandler.h
#ifndef CONNECTIONHANDLER_H
#define CONNECTIONHANDLER_H
#include <QTcpServer>
class ConnectionHandler : public QObject
{
Q_OBJECT
public:
ConnectionHandler();
public slots:
void newConn();
private:
QTcpServer *server;
};
#endif // CONNECTIONHANDLER_H
connectionhandler.cpp
#include "connectionhandler.h"
#include <QTextStream>
ConnectionHandler::ConnectionHandler() {
server = new QTcpServer;
server->listen(QHostAddress::LocalHost, 8080);
QObject::connect(server, SIGNAL(newConnection()),this, SLOT(newConn()));
}
void ConnectionHandler::newConn() {
QTextStream out(stdout);
out << "new kanneksan!\n";
out.flush();
}
main.cpp
#include <QCoreApplication>
#include "connectionhandler.h"
int main(int argc, char* argv[]) {
QCoreApplication app(argc,argv);
ConnectionHandler handler;
return app.exec();
}
Now, running this program sends it into an infinite loop looking for new connections.
Observation: if I don't call app.exec(), the program returns immediately (as it should).
Question: why?
Question: if I had connected the slot as a queued connection, when would the slot invocation be performed?
Question: if app.exec() is an infinite loop of sorts, how does the newConnection() signal ever get emitted?
Big Question: Is their any "second thread" involved here? (I expect a no, and a stunningly elegant explanation :) )
Thanks,
jrh
PS: who else has this nested parenthesis syndrome? like "(.. :))" or "(.. (..))"?
If you don't call app.exec() then the program hits the end of your main() and ends. (Why? There's no more code to execute!)
app.exec() is an infinite loop of the following style:
do
{
get event from system
handle event
}
while (true);
If you use a queued connection, then the event is added to your event queue, and it will be performed at some point in the future during the app.exec() loop.
There is no second thread in your program. Events are delivered asynchronously by the OS, which is why it appears that there's something else going on. There is, but not in your program.
app.exec() enters the main event loop and waits until exit() is called.
update:
The main event loop and the glue code generated by qmake take care of transferring the event message from the QTcpServer to your ConnectionHandler.
If you'd use queued connections the actual connection to the QTcpServers slot would be delayed until the main event loop delivers the connection request.
When you say it enters an infinite loop, you mean it crashes the program?
Because listen() will become part of the main application event loop the way you have it set up, which runs until you exit the program. I'm not sure what the problem is. There should be no trouble of your signal being emitted in the main application event loop (exec()) whenever one is encountered.
If you like, you could have your ConnectionHandler class extend QThread and run listen() in it's own thread, apart from the main application loop.