QProgressbar unresponsive with qthread

[J.Hilk]

@meganathan said in QProgressbar unresponsive with qthread:

FelixThread *ansysThread = new FelixThread(tempDirPath,ansysPath,felixMutex);
ansysThread->start();
qApp->processEvents(QEventLoop::ExcludeUserInputEvents);
ansysThread->wait();

My question is , when ansysThread is started, does ansysthread->wait() blocks the progress bar update or process->waitforfinished(-1) is blocking the main GUI thread to update

yes it does
https://doc.qt.io/qt-5/qthread.html#wait

[meganathan]

@J.Hilk hi,

Is there any alternative function to Qthread::wait() which doesn't blocks main() GUI thread.

[J.Hilk]

@meganathan
well, yes, the finished signal
https://doc.qt.io/qt-5/qthread.html#finished

[meganathan]

@J.Hilk

I tried like this
QEventLoop loop;
ansysThread->start();
loop.exec();
connect(ansysThread, SIGNAL(finished()),this,SLOT(onQProcessFinish()));

finished() signal emits before Qthread::run() completes the execution. Hot to approach this, if i use ansysthread->wait() it blocks the main GUI thread.. So please suggest any other suggestion.

[jsulm]

@meganathan said in QProgressbar unresponsive with qthread:

QEventLoop loop;
ansysThread->start();
loop.exec();
connect(ansysThread, SIGNAL(finished()),this,SLOT(onQProcessFinish()));

Why do you block your thread with

loop.exec();

?!
It should be

connect(ansysThread, SIGNAL(finished()),this,SLOT(onQProcessFinish()));
ansysThread->start();

[meganathan]

@jsulm

I need to wait for thread to completed the process..how can i approach without using ansysthread->wait()

[jsulm]

@meganathan Why do you need to wait? If you wait you block the waiting thread - and then you complain that the thread is blocking and progress bar not updating?! And if you want to wait then what is the point to use threads?
You get the finished() signal when it is finished and can do whatever needs to be done when the thread finishes.
Qt is asynchronous and you should avoid waiting for something. Learn how to program in an asynchronous way else there is no point to use Qt or threads.

[meganathan]

@jsulm
Based of the files generated by script inside ansysthread, i need to proceed after the script completes execution. i am struct there without using ansysthread->wait()

[jsulm]

@meganathan Again: you know when the thread finishes - you get the finished() signal. So, why don't you simply connect a slot to that signal and process in that slot?

[meganathan]

@jsulm
By the time thread emits finished() signal, all my remaining things that to done(after script execution) are already executed. This makes no sense. By using QEventloop can we block the until thread emits finished() signal.?

[J.Hilk]

@meganathan as a rule of thumb,

if you're using QEventLoop or QProcessEvents, you're doing something wrong(95% chance).

[jsulm]

@meganathan said in QProgressbar unresponsive with qthread:

all my remaining things that to done(after script execution) are already executed

Then do all these things in the slot connected to finished() signal as I already suggested.
"By using QEventloop can we block the until thread emits finished() signal.?" - you can, but then your progress bar will not update which was your first question in this thread, right? And if you anyway want to block, then why do you want to use threads? I don't see the point...

[J.Hilk]

here:

#ifndef SUBTHREAD_H
#define SUBTHREAD_H

#include <QObject>
#include <QThread>

class SubThread : public QThread
{
    Q_OBJECT
public:
    explicit SubThread(QObject *parent = nullptr);

protected:
    virtual void run()override;

signals:
    void status(int stat);

public slots:
};

#endif // SUBTHREAD_H

#include "subthread.h"
#include <QTime>

SubThread::SubThread(QObject *parent) : QThread(parent)
{

}

void SubThread::run()
{
    QTime t;
    t.start();

    while(t.elapsed() < 10000){
        if(t.elapsed() % 100 == 0)
            emit status(t.elapsed()/100);
    }
}

#include <QApplication>
#include <QProgressBar>
#include "subthread.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QProgressBar bar;
    bar.show();

    SubThread myThread;

    QObject::connect(&myThread, &SubThread::status, &bar, &QProgressBar::setValue);
    QObject::connect(&myThread, &SubThread::finished, &a, &QApplication::quit);
    myThread.start();


    return  a.exec();
}

[JonB]

@J.Hilk

  while(t.elapsed() < 10000){

Now, you doubtless know more than I about threads, because I don't use them. But I don't get this approach. It looks like you're spinning an awfully busy loop. It's true than your main thread will run uninterrupted, but half the CPU will be executing this all the time/your mobile battery is going to drain, no? Could you explain?

This is why the OP is asking about QEventLoop etc. Does a QThread run its own event loop? Does it exit when it gets to end of run() or does it have to be terminated explicitly?

[jsulm]

@JonB I think this is just a simple example not optimised for real world usage :-)

[J.Hilk]

@JonB I usually don't subclass QThread, but that's what the OP did so I went with the example.

It looks like you're spinning an awfully busy loop. It's true than your main thread will run uninterrupted, but half the CPU will be executing this all the time/your mobile battery is going to drain, no?

absolute correct. But this is really only a simulation of any busy calculation, that also shows, you don't need to to pause or spin the event loop to emit a signal that is handled in another thread.

Does a QThread run its own event loop? Does it exit when it gets to end of run() or does it have to be terminated explicitly?

the default QThread does indeed spin its own event loop. By overwriting run my subclass does this not by default.
everything inside run is executed in the new thread
If I want an event loop in SubThread, I would have to call exec()at the end of the run function. If not, the thread finishes as soon as the run function finishes.

[JonB]

@jsulm , @J-Hilk
Thank you for replies. I think I would really need to play with QThreads if it is to sink in! I thought this was code the OP was to type in & use, that's what happens here!

So just to be clear: if one really wanted to do what you have here --- emit a signal every so often --- one would set up a QTimer in the thread and then execute QThread::exec(), right?

[J.Hilk]

@JonB If you want a regular Signal from the thread, triggered by a Timer then yes.

But the QTimer instance should be created inside run, or a function called from inside run. Otherwise the QTimer lives in the parent thread.

[meganathan]

@jsulm

QThread::finished signal() emits even before the thread completed it's process. The main reason for me to go for thread approach is because on using QProcess::waitforfinished(-1) makes my QProgress bar "Not responding" state.

Even i tried to emit the signal inside the Qthread::run() to update the GUI but on using thread->wait() makes GUI unresponsive yet again.

[JonB]

@meganathan

QThread::finished signal() emits even before the thread completed it's process.

While you wait for @jsulm to reply, I imagine he'll want to ask you what you mean by the above? If you're not calling exec() it should emit when run() completes.