I have a QThread on my embedded device. every time I run the application my thread stuck after second run. I try to kill my thread after first run. Still device stuck after second run. I couldn't run my thread correctly.
Here is my code;
void ThreadCurrency::run()
{
QMutex mutex;
mutex.lock();
if(this->CurrencyStop == true)
{
mutex.unlock();
return;
}
QByteArray strdata;
// Create QProcess object
processCurrency = new QProcess();
processCurrency->start("curl --insecure -v --cacert /data/ca/cert.pem https://secure.*******************/fx.jsp");
if (processCurrency->waitForStarted(-1))
{
while(processCurrency->waitForReadyRead(-1))
{
strdata += processCurrency->readAllStandardOutput();
}
QMessageBox msgBox1;
msgBox1.setWindowTitle("eCode Read");
msgBox1.setText(strdata);
msgBox1.exec();
}
else
{
while(processCurrency->waitForReadyRead(-1))
{
strdata += processCurrency->readAllStandardError();
}
QMessageBox msgBox1;
msgBox1.setWindowTitle("eCode Error");
msgBox1.setText(strdata);
msgBox1.exec();
}
mutex.unlock();
sleep(1);
//*****************************************************************
emit CurrencyChanged(aGBP, aEUR, aUSD, sGBP, sEUR, sUSD);
}
** The Output shows in a json format:**
{
"date": "20171107", "currency": {
"dolar": {
"buy": "3,8200",
"sale": "3,9050",
"e_sale": "3,8200"
},
}
}
Thank you for suggestion. The QMutexLocker can’t work in my embedded device. QMutex and the QThread is the closes I can get in my device.
My problem is the below line: emit CurrencyChanged(aGBP, aEUR, aUSD, sGBP, sEUR, sUSD); The line runs but It doesn’t fire onCurrencyChanged SLOT. Anything in onCurrencyChanged doesn’t run. My main thread code is:
currencyThread = new ThreadCurrency (this);
connect(currencyThread,SIGNAL(CurrencyChanged(QString, QString, QString, QString, QString, QString)), this, SLOT(onCurrencyChanged (QString, QString, QString, QString, QString, QString)));
currencyThread->CurrencyStop = false;
currencyTimer = new QTimer(this);
connect(currencyTimer, SIGNAL(timeout()),this, SLOT(showCurrencyStatus()));
currencyTimer->start(30000);
void MainWindow::onCurrencyChanged(QString aGBP, QString aEUR, QString aUSD, QString sGBP, QString sEUR, QString sUSD)
{
// SHOW Currency
ui->lblALIS_STG->setText(aGBP);
ui->lblALIS_EUR->setText(aEUR);
ui->lblALIS_USD->setText(aUSD);
QCoreApplication::processEvents();
}
1) You are not allowed to access Widgets in a thread besides the main thread.
Thus move all QMessageBox code to the main thread (e.g. after receiving the CurrencyChanged signal).
2) Make sure, that the CurrencyChanged signal is connected using a QueuedConnection, otherwise, your GUI will be executed inside the secondary worker thread.
3) Do not use QMutex directly, use a QMutexLocker instead
4) Why do you need the Mutex anyhow? Locking based on (arbitrary) input thus arbitrary time is close to deadlocking your application.
Related
I'm developing an application which parses a list of binary files and saves the results into a database. The processing of the files takes a rather long time. Therefore I'm showing the user a progress bar and a list of processed files. When a file is successfully processed, I want to update the processbar. If the user aborts the processing (i.e. clicks on the window's 'x' -> &ParseAssistant::rejected), I need to kill the thread and delete the allocated objects (i.e. PluginWorker* and QThread*).
/* mainwindow.cpp */
ParseAssistant parseWindow(files.size());
QThread* thread = new QThread();
PluginWorker* worker = new PluginWorker(pluginConnector, pluginProcessor, files);
worker->moveToThread(thread);
// Update GUI (progressbar + filelist)
connect(worker, &PluginWorker::updateProgress, &parseWindow, &ParseAssistant::updateProgress);
connect(thread, SIGNAL (started()), worker, SLOT (process()));
connect(worker, SIGNAL (finished()), thread, SLOT (quit()));
connect(thread, SIGNAL (finished()), thread, SLOT (deleteLater()));
connect(worker, SIGNAL (finished()), worker, SLOT (deleteLater()));
// Stop PluginWorker on 'x'-click
connect(&parseWindow, &ParseAssistant::rejected, worker, &PluginWorker::stop);
connect(worker, &PluginWorker::finished, &parseWindow, &ParseAssistant::parsingFinished);
thread->start();
parseWindow.exec();
First, I'm creating a QDialog (ParseAssistant) which contains the progressbar and the list of processed files. Afterwards I create a Worker-Thread-pair and bind them as described in 'How To Really, Truly Use QThreads'. The 'pluginConnector' has access to the plugin an parses the files; the pluginProcessor writes the results to a database.
/* pluginworker.cpp */
PluginWorker::PluginWorker(PluginConnector& pc, PluginProcessor& processor, QStringList list)
{
connect(this, SIGNAL(parseNext(int)), this, SLOT(process(int)));
}
// Called on 'x'-press
void PluginWorker::stop()
{
isStopped = true;
}
void PluginWorker::process(int idx)
{
if (isStopped) {
emit finished();
return;
}
if (0 <= idx && idx < files.length()) {
/*
* Parse file using PluginConnector and
* use result with PluginProcessor
*/
emit updateProgress(idx+1, error, source);
emit parseNext(idx+1);
} else {
emit finished();
}
}
I use signals/slots to call parseNext, because this allows Qt to call stop() (when &ParseAssistant::rejected signal is received). An alternative would be to iterate over the files and call QCoreApplication::processEvents to process signals.
This construct mostly works, but crashes when I abort the process using the 'x'. I can't track down exactly what crashes the application, but I'm fairly certain that my approach is flawed, because the 'worker' and the 'pluginConnector/pluginProcessor' live in different threads, but I don't know how to correctly use this.
I use the following code to talk to a USB-serial port device:
#include "masterthread.h"
#include <QtSerialPort/QSerialPort>
#include <QTime>
#include "Windows.h"
#include "Psapi.h"
#include <QDebug>
QT_USE_NAMESPACE
MasterThread::MasterThread(QObject *parent)
: QThread(parent), waitTimeout(0), quit(false)
{
}
MasterThread::~MasterThread()
{
mutex.lock();
quit = true;
cond.wakeOne();
mutex.unlock();
wait();
}
void MasterThread::run()
{
bool currentPortNameChanged = false;
QSerialPort serial;
serial.setPortName("COM3");
serial.setBaudRate(57600);
serial.setStopBits(static_cast<QSerialPort::StopBits>(1));
serial.setDataBits(static_cast<QSerialPort::DataBits>(8));
serial.setParity(static_cast<QSerialPort::Parity>(0));
serial.open(QIODevice::ReadWrite);
//Tell the serial port connected device to start talking
//--------------------------------------
const char init[] = { 0x0d, 0x0d, 0x0d };
serial.write(init, sizeof(init));
const char* cmd = "mavlink stop\n";
serial.write(cmd, strlen(cmd));
serial.write(init, 2);
cmd = "uorb start";
serial.write(cmd, strlen(cmd));
serial.write(init, 2);
cmd = "sh /etc/init.d/rc.usb\n";
serial.write(cmd, strlen(cmd));
serial.write(init, 4);
serial.waitForBytesWritten(100);
int i = 0;
int j = 0;
forever
{
//Write test data out
//-----------------------------
QByteArray test(2000, 't');
serial.write(test);
bool check = serial.waitForBytesWritten(100);
if (!check)
{
qDebug() << "FAIL: " << j++;
}
if (serial.waitForReadyRead(20))
{
QByteArray responseData = serial.readAll();
while (serial.waitForReadyRead(10))
responseData += serial.readAll();
QString response(responseData);
qDebug() << response;
}
QThread::msleep(20);
//Print memory usage
//---------------------------------------------------
if (i++ % 10 == 0)
{
PROCESS_MEMORY_COUNTERS memcount;
if (!GetProcessMemoryInfo(GetCurrentProcess(), &memcount, sizeof(memcount))) return;
qDebug()<<"----------------------------" << memcount.WorkingSetSize / 1024 << "KB memory used";
}
} // end foever
qDebug() << "Exiting forever loop";
}
with a simple main.cpp as:
#include <QApplication>
#include "masterthread.h"
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MasterThread thread;
thread.start();
return app.exec();
}
But the memory usage keeps increasing, like 5~10MB per hour as if there are some leakage.
The device is suppose to be connected for days and weeks...
What am I doing wrong here? I am on Qt5.6 windows7 debug
Many Qt Components have an implicit dependency on its event loop.
While you are starting the main threads event loop with the call to app.exec(); you are not handling events generated by the QObjects created in the QThread MasterThread thread;. The details and nuances of Event handling in Qt are very well described on this page: https://wiki.qt.io/Threads_Events_QObjects#Threads_and_QObjects
But the solution boils down to: if you want to be able to process queued up Qt events in a thread where you are processing some long-running task you should call QCoreApplication::processEvents(); from time to time. This will prevent Qt events from endlessly queueing up.
EDITED after looking on the code Qt 5.7,5.6,5.5 and reading docs.
As an answer is already accepted, I would just add some thoughts here as it's too long for comments.
Keep things short - an answer you accepted is wrong..
There are two sides of the story. And as SO answers often taken 'as it is as long as they work' I'd like to explain myself...
If you look on a code provided - there is nothing wrong with it. All objects are properly stack allocated and should be destroyed automatically.
Point is that QtSerial uses deleteLater() and then a question - how to delete those allocations properly.
If any module/object/code uses deleteLater() it requires an event loop, if deleteLater() called on a thread without event loop, object will be deleted after thread is terminated. As long as there is no event loop running for code above, processEvents will no work.. actually processEvents() is not something which is used for this, because a whole idea to return from the context which is called deleteLater() and have a next run, and that's checked in the Qt Source Code, so calling processEvent() straight after without incrementing loop count will do nothing at all, that's why answer you accepted is totally wrong.
Conclusion:
If any object requires event loop running it should be EXPLICITELY stated in the documentation as there is nothing wrong in using QIODevice in sync mode outside event loop.
So at my opinion,point is - its a bug in the QT Serial itself which I suggest you report.
In general it's really wrong practice for Qt to run never-ending loops..
It's much much better and cleaner to use QObject Worker tactic which is pushed to the thread, have proper even loop running etc.
For small 'threaded' tasks it's much better to use QtConcurrent.
Proper Workaround:
you will have a thread with properly running event loop and a timer firing at 20ms to do your things
// main thread:
class Worker: public QObject {
public:
Worker();
public slots:
onInit() {
// initialize everything
startTimer(20);
}
protected:
void timerEvent(..) {
// do your things every 20ms
}
}
...
QThread * pWorkerThread = new QThread();
pWorkerThread->setObjectName(QString("Serial"));
Worker * pWorker = new Worker();
Worker->setObjectName(QString("Common Storage Impl"));
Worker->moveToThread(WorkerThread);
connect(pWorkerThread, SIGNAL(started()), pWorker, SLOT(onInit()));
connect(pWorkerThread, SIGNAL(finished()), pWorker, SLOT(deleteLater()));
connect(pWorkerThread, SIGNAL(finished()), pWorkerThread, SLOT(deleteLater()));
pWorkerThread->start();
...
My Qt application talks to a serial device, and occasionally has to wait for this device to send a byte. To accomplish this, I create a new eventloop that exits as soon as there is information available in the serial buffer:
unsigned char MyClass::waitForDevice(int timeout)
{
QEventLoop wait;
connect(d_serial, SIGNAL(readyRead()), &wait, SLOT(quit()));
if (timeout > 0)
QTimer::singleShot(timeout, &wait, SLOT(quit()));
wait.exec();
return static_cast<unsigned char>(d_serial->read(1)[0]);
}
Now the problem is that, while the application is waiting, i.e. while the eventloop is running, I need to be able to communicate to the serial device when a button is pressed in the GUI. Naively, I tried connecting a signal to a slot that does this, but I found that the slot is only executed after the eventloop is terminated.
I tried, without any luck, to have a seperate QThread running that calls qApp->processEvents() in an infinite loop, which is terminated when the eventloop is terminated. This didn't work, and I'm not quite sure why not. What is the canonical way to resolve this?
You're thinking synchronously in a pre-C++1z world. In C++14 (and prior) asynchronous programming, there is mostly no place for a notion of a wait that is implemented as a function that returns when the wait is over (switch-based coroutine hacks excepted). You are also not using the fact that your application is stateful, and the state transitions can be expressed in a state machine.
Instead, you should simply act on data being available. Presumably, your application can be in multiple states. One of the states - the one where you have to wait for input - is simply exited when the input arrives.
The example below uses a simple process-local pipe, but it would work exactly the same if you were using a serial port - both are a QIODevice and emit requisite signals. We start with the project file.
# async-comms-32309737.pro
QT += widgets core-private
TARGET = async-comms-32309737
CONFIG += c++11
TEMPLATE = app
SOURCES += main.cpp
To make things simple, the pipe implementation reuses the QRingBuffer private class from Qt. See this question for more fleshed-out implementation(s).
// main.cpp
#include <QtWidgets>
#include <private/qringbuffer_p.h>
/// A simple point-to-point intra-application pipe. This class is not thread-safe.
class AppPipe : public QIODevice {
Q_OBJECT
AppPipe * m_other { nullptr };
QRingBuffer m_buf;
public:
AppPipe(AppPipe * other, QObject * parent = 0) : QIODevice(parent), m_other(other) {
open(QIODevice::ReadWrite);
}
void setOther(AppPipe * other) { m_other = other; }
qint64 writeData(const char * data, qint64 maxSize) Q_DECL_OVERRIDE {
if (!maxSize) return maxSize;
m_other->m_buf.append(QByteArray(data, maxSize));
emit m_other->readyRead();
return maxSize;
}
qint64 readData(char * data, qint64 maxLength) Q_DECL_OVERRIDE {
return m_buf.read(data, maxLength);
}
qint64 bytesAvailable() const Q_DECL_OVERRIDE {
return m_buf.size() + QIODevice::bytesAvailable();
}
bool isSequential() const Q_DECL_OVERRIDE { return true; }
};
We start with a simple UI, with one button to restart the state machine, another to transmit a single byte that will be received by the client, and a label that indicates the current state of the state machine.
int main(int argc, char *argv[])
{
QApplication a { argc, argv };
QWidget ui;
QGridLayout grid { &ui };
QLabel state;
QPushButton restart { "Restart" }, transmit { "Transmit" };
grid.addWidget(&state, 0, 0, 1, 2);
grid.addWidget(&restart, 1, 0);
grid.addWidget(&transmit, 1, 1);
ui.show();
We now create the simulated device and the client pipe endpoints.
AppPipe device { nullptr };
AppPipe client { &device };
device.setOther(&client);
The state machine has three states. The s_init is the initial state, and is exited after a 1.5s delay. The s_wait state is only exited when we receive some data (a byte or more) from the device in that state. In this example, receiving the data in other states has no effect. The machine is set to restart automatically when stopped.
QStateMachine sm;
QState
s_init { &sm }, // Exited after a delay
s_wait { &sm }, // Waits for data to arrive
s_end { &sm }; // Final state
QTimer timer;
timer.setSingleShot(true);
sm.setInitialState(&s_init);
QObject::connect(&sm, &QStateMachine::stopped, &sm, &QStateMachine::start);
QObject::connect(&s_init, &QState::entered, [&]{ timer.start(1500); });
s_init.addTransition(&timer, SIGNAL(timeout()), &s_wait);
s_wait.addTransition(&client, SIGNAL(readyRead()), &s_end);
To visualize the state machine's progress, we assign the state label's text property in each of the states:
s_init.assignProperty(&state, "text", "Waiting for timeout.");
s_wait.assignProperty(&state, "text", "Waiting for data.");
s_end.assignProperty(&state, "text", "Done.");
Finally, the restart button stops the state machine - it will self-restart then. The transmit button simulates the device sending one byte of data.
QObject::connect(&restart, &QPushButton::clicked, &sm, &QStateMachine::stop);
QObject::connect(&transmit, &QPushButton::clicked, [&]{
device.write("*", 1);
});
We start the machine, enter the event loop, and let Qt follow our directions onwards from here. The main.moc file is included for it contains the metadata for AppPipe.
sm.start();
return a.exec();
}
#include "main.moc"
There are several Types of which Signals and Slots can be connected.
See: http://doc.qt.io/qt-4.8/qt.html#ConnectionType-enum
Have you tried Qt::DirectConnection: connect(d_serial, SIGNAL(readyRead()), &wait, SLOT(quit()),Qt::DirectConnection); ?
I work with QTcpSocket. I need any write/read calls to the socket to be synchronous (blocking).
I know there is waitForReadyRead() and waitForBytesWritten(), but those two methods are marked in Qt documentation as they can fail randomly under Windows. I cannot affort this.
The blocking read is the most important (as reading comes always after writting a command to the other peer, so I know that if data reaches the other peer, it will answer).
I have tried 2 approaches.
First:
QByteArray readBytes(qint64 count)
{
int sleepIterations = 0;
QByteArray resultBytes;
while (resultBytes.size() < count && sleepIterations < 100)
{
if (socket->bytesAvailable() == 0)
{
sleepIterations++;
QThread::msleep(100);
QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents);
continue;
}
resultBytes += socket->read(qMin(count, socket->bytesAvailable()));
}
return resultBytes;
}
This should wait for bytes to be available for reading on the socket, processing the event loop in the mean time, so the socket is doing it's necessary internal stuff.
Unfortunately - for unknown to me reason - the bytesAvailable() sometimes returns correct number of bytes, but sometimes it never returns anything greater than 0.
I know in fact that there was data to be read, because it used to work with the second approach (but it has it's own problems).
Second:
I have a kind of signal "blocker", which blocks current context and processes event loop, until certain signal is emitted. This is the "blocker":
SignalWait.h:
class SignalWait : public QObject
{
Q_OBJECT
public:
SignalWait(QObject *object, const char *signal);
bool wait(int msTimeout);
private:
bool called = false;
private slots:
void handleSignal();
};
SignalWait.cpp:
SignalWait::SignalWait(QObject* object, const char* signal) :
QObject()
{
connect(object, signal, this, SLOT(handleSignal()));
}
bool SignalWait::wait(int msTimeout)
{
QTime timer(0, 0, 0, msTimeout);
timer.start();
while (!called && timer.elapsed() < msTimeout)
QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents);
return called;
}
void SignalWait::handleSignal()
{
called = true;
}
and then I used it like this:
SignalWait signalWait(socket, SIGNAL(readyRead()));
// ...
// socket->write(...);
// ...
if (!signalWait.wait(30000))
{
// error
return;
}
bytes = socket->read(size);
This approach seems to be working better, but it also fails from time to time. I don't know why. It's like the readyRead() signal was never emitted and the SignalWait keeps waiting, until it times out.
I'm out of ideas. What is the proper way to deal with it?
I would suggest to use the asynchronous approach but if you really want to go with the synchronous way, then a better way is to use a local event loop:
QTimer timer;
timer.setSingleShot(true);
QEventLoop loop;
loop.connect(socket, SIGNAL(readyRead()), SLOT(quit()));
connect(&timer, SIGNAL(timeout()), &loop, SLOT(quit()));
while (resultBytes.size() < count)
{
timer.start(msTimeout);
loop.exec();
if(timer.isActive())
resultBytes += socket->read(qMin(count, socket->bytesAvailable()));
else
break;
}
Here it waits until count bytes are read or the the timeout reaches.
The code is given as:
class USBCamCaptureThread : public QThread
{
Q_OBJECT
void run() {
while (!threadQuit){
if (imageReaded){
buffer->reset();
Request = http->get (url->path(),buffer););
}
MG::SLEEP::msleep(250);
}
}
public:
USBCamCaptureThread(){
QFile file("setting_files/cameraIP.txt");
QString line = "192.168.1.5:80"; //default value
if(file.open(QIODevice::ReadOnly)) {
QTextStream in(&file);
line = in.readLine();
}
file.close();
url = new QUrl(line);
http = new QHttp(this);
buffer = new QBuffer(&bytes);
threadQuit = false;
imageReaded = true;
}
~USBCamCaptureThread(){
}
public slots:
void Finished(int requestId, bool error){
QImage localImage;
localImage.loadFromData(bytes);
QImg = localImage;
bytes.clear();
emit signalUSBImageRead();
}
Note that the Finished() is in the main thread, and the run() is in a worker thread.
May question is by reading/writing to the bytes and buffer in separate threads, will it cause thread related issues?
If Finished is called while run is active, then yes, you have a problem. Sharing data between two threads that run in a pipeline (serially) isn't necessarily a problem. Accessing non-threadsafe, shared data between two threads at the same time is always a problem. I haven't used Qt in many years so QBuffer or QImage::loadFromData may offer thread safety guarantees of their own as well.