QThread with multiple methods

Christian Ehrlicher

@JohnCu said in QThread with multiple methods:

connect(&worker_obj, &Worker::update_plot, this, &App::plot_results, Qt::DirectConnection);

This is wrong and will lead to crashes. Also the blockingQueued stuff is not needed - at least I don't see a need for it. Apart from that your code does not compile.

JohnCu

@Christian-Ehrlicher Please take look one more time at Worker::acquire_data(), because i have forgotten to add something significant. Plot needs to be updated before stepping into subsequent line, because then, some calculations are taking place, which modify vectors used to visualize results. I have also added plot class
When i dont set Qt::DirectConnection the algorithm goes well, but as a result i have multiple plot of the same vector, and the data is the one acquired just before showing gui information message. So to sum up, i click run in gui, then some data is acquired multiple times and after a while, both result and gui msgbox appear.
It would be hard for you to compile it, because you dont have the hardware necessary to generate the result vectors. Moreover, a algorithm (in worker class) is sophisticated, and would make whole code hard to be analyzed. Thats why i isolated the problem and passed it like this.

Christian Ehrlicher

@JohnCu said in QThread with multiple methods:

Please take look one more time

You still not fixed my comments. DirectConnection is wrong!

JohnCu

@Christian-Ehrlicher said in QThread with multiple methods:

DirectConnection

I understand, at first there was no connection specifier in this connect call. In previous post I described what happened then. So do you see any solution for mentioned problem?

Christian Ehrlicher

@JohnCu said in QThread with multiple methods:

So do you see any solution for mentioned problem?

Don't use blocking and direct connections when working with threads. I don't see a problem calling a slot when a push button is pressed inside the thread which then triggers the execution.

JohnCu

@Christian-Ehrlicher The situation is as follows, I want to have my gui responsible all the time, but workers thread needs to emit signal to gui in order to plot the results. And the results needs to be ploted before subsequent step in workers thread. Now, data is plotted while app gets stucked on gui msgbox. I mean, when I dont use blocking and direct connections for update plot.

Christian Ehrlicher

@JohnCu said in QThread with multiple methods:

And the results needs to be ploted before subsequent step in workers thread.

But why? But I don't care - simply emit another signal once the plotting is done so your thread can continue to calculate.

JohnCu

@Christian-Ehrlicher Ok, I will try. Thank you anyway, for all of your replies :)

JohnCu

@Christian-Ehrlicher One more thing. I have menaged to handle stuff in workers thread (after emitting signal which initiates plotting, workers thread waits for succesful visualization), but there is still a problem in on_Run_triggered() method in App.cpp. After initiating result acquisition (emit onRun();) the main thread also needs to wait till operation is finished. Moreover, gui needs to be responsible all the time. When i create here a loop, which waits for signal from
workers class, the gui thread is stucked in this loop and visualization in gui is impossible. Are there any methods which, will enable me to have responsible thread (in order to plot according to signal from worker), but paused on emit onRun() line?

Christian Ehrlicher

Show a modal wait dialog.

JohnCu

@Christian-Ehrlicher But does not a modal wait dialog assume, that everything, except this dialog window is unable to be clicked? I want to achieve both gui responsibility and live data visualization.
For now I have a following loop:

{
	QEventLoop loop;
	loop.connect(&workers_obj, SIGNAL(on_ready()), SLOT(quit()));
	QFuture<void> future;
	future = QtConcurrent::run(&this->workers_obj, &Worker::acquire_data);
	loop.exec();
}

Here I use on_ready() signal generated at the end of acquire_data() method. Everything works fine, until I want to cancel computation in worker thread. It leads to null-pointer access etc.

Christian Ehrlicher

You wanted to wait in the main dialog (for whatever reason) - I told you a solution.
Now you tell me you won't block the ui - so don't block it and connect a slot to the finished signal of the thread.

JohnCu

@Christian-Ehrlicher Ok, let me explain the situation one more time. I launch a function from a gui thread (gui class code). Then i need to wait for the function to finish its job, before i go to a subsequent line. However, mu gui thread event loop needs to be active all the time, in order to enable data plotting. I can not freeze gui thread, I need to have it responsible, but it needs to be waiting in a line of launching function from workers object. There should be something like "do subsequent line, but first perform action prompted by an indicated signal". For now it is handled in a loop mentioned before, but I know, that it is not an optimal solution...

Christian Ehrlicher

Again: connect a signal which is emitted from the thread when the first part is finished. Connect this signal to a slot in the gui thread which does the work you need to do in the gui thread which then emits another signal to do the next work in the thread.

JohnCu

@Christian-Ehrlicher Yes, I added such signal. But how should I check if the signal was emitted? I can not do a while loop, which constantly checks whether signal was emitted, because gui thread will be locked in such loop. Maybe you meant something else?

J.Hilk

@JohnCu you don't need to check that yourself

simply connect a slot to the signal, as soon as it is emitted and your main application is in no loop (infinite loop for example) the slot will be called!

JohnCu

@J-Hilk Yes, but my workers thread computation are a little bit time consuming, and I need to be sure, that before going to subsequent line in gui code (just after launching computation on workers thread) the computations are done. Your approach would work, if there is no more code in function, inside which workers thread method is launched.

J.Hilk

@JohnCu
I don't see the problem, YOU decide when the signal is emitted inside your code, don't you?

Emit the allDone signal when you're all done, and not before

JohnCu

@J-Hilk Yes, of course, there is no problem with emitting a signal from workers thread, I do it when computations are done. But, take look at this code from gui class:

emit onConnecttoHardware();

// if connected to hardware
QMessageBox::information(this, "Message", "Hardware connected");

First i launch action, then i show, that it is finished. however, after emitting a signal to start the action, the main thread goes straight to show QMessageBox, which can not be prompted before computations are done... I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting, because i need to plot some results, which are also prompted by a signal emitted from workers thread. If I do as you suggested, main thread displays messagebox immediately, before action finished (allDone signal is emitted)...

aha_1980

@JohnCu said in QThread with multiple methods:

I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting,

And this, you have to understand, is a discrepance.

You cannot wait in GUI threads.

What you probably want to do is, to disallow user input until the allDone signal is received. And that's how it's usually done in professional apps.

You most likely also want your user to be able to abort the process, in case something goes wrong. All that is impossible if the GUI thread stucks.

Regards