Running QProcess in Thread to not freeze GUI on waitForFinished()

[vezprog]

I am having a little issue with my QProcess. I have an application that is basically and overlay to spawning other applications (aka, a window with buttons that once one of the buttons is clicked, a new executable is spawned).

The only way I though of doing this was to start a QProcess when the button is clicked (to open the desired app). Unfortunately, I ran into the issue that the GUI keeps freezing when after I start the process and waitForFinished(-1).

In turn, I chose the route of creating a QThread, with the QProcess in it, so when it runs, I can waitForFinished(-1) without freezing the GUI.

Now I am running into more errors with this logic in which my QThread is throwing debug errors. Heres the code.

This is the function that is a slot to the utility button on my main form.
@
void mainwindow::utils()
{
threadutils process;
process.start();
}
@

Heres the class file for the thread
@
#include "threadutils.h"

threadutils::threadutils(QObject *parent) :
QThread(parent)
{
program = "utils/converter";
}

void threadutils::run()
{
QProcess converter;
converter.start(program);
while(converter.waitForFinished(-1) == false){
QCoreApplication::processEvents();
}
}
@

Is this the proper way to approach this? I have about 7 buttons on my main form and was planning to create a thread for each one, either that or just create one thread with a case statement and have a global pointing to which button was pushed. Either way, I feel like this should work.

My build output crashes and says:
QThread: Destroyed while thread is still running
QMutex: mutex destroy failure: Device or resource busy

I dont really understand this since I should be in a while loop...

[alexisdm]

You allocated the threadutils object on the stack, so it is destroyed at the end of the utils() function. The QThread object should exist as long as the thread is running, so you should allocate it on the heap/dynamically.

But anyway, you don't need to have a thread for each process, or even to subclass QThread to use it. You can look at the Worker class in "that article.":http://developer.qt.nokia.com/wiki/Threads_Events_QObjects#913fb94dd61f1a62fc809f8d842c3afa .

[andre]

Another approach would obviously be to simply not use the waitFor* methods, but instead use the relevant signals and slots. That way, you don't need any threads and you can still keep your application responsive.

[vezprog]

I thank you for your responses. Andre, I dont think that will work since the applications that I am trying to spawn do not exist in the project itself, they are just separate executable's build on the system. Therefore, I have no way of communicating with the other applications using a protocol of my choice...since I cant modify code.

I will look at alexisdm's way right now! Thank you!

[andre]

Yes, you can. QProcess supports signals that allow you to use it asynchronously.

[cincirin]

Why not follow the Andre's suggestion without using threads pitfall ?
Just connect your slot to "QProcess::finished":http://doc.qt.nokia.com/latest/qprocess.html#finished signal. You will be informed when the process ends + process exit code.

[goetz]

Maybe using a [[Doc:QProgressDialog]] to inform the user that something's going on.