Infinite wait when stopping QThread event loop and then calling wait
-
It works fine for me by accident since it's a timing issue in your code.
You got the signal to stop the thread and handle it in setKeepStressTesting(). But before this is done, QThread::quit() was called and all active eventloops were notified about it and exited. But then you call processEvents() again and start the eventloop again.
Use QThread::interrupt() and QThread::isInterruptionRequested() since this sets an internal QThread variable which prevents the restart of the eventloop handling.@Christian-Ehrlicher I built the example on Ubuntu 20.04 LTS and there's absolutely no problem.
Comment out the line that invokes setKeepStressTesting, let the main thread call quit and wait on the QThread object, wait for the stress test thread to finish running gracefully and unlike on Windows 10, the wait() will return and everything is alright (no freeze).
I will file a bug report since the behavior is not the same on both platforms. The Windows port clearly has a problem.
As for the problem with the QThread::finished signal, the documentation is incorrect. The behavior is the same on both Windows and Ubuntu : the slot of the object belonging to a QThread is executed on the thread manged by that QThread. So the event loop is still running after that signal is fired (or maybe it is restarted and then shut properly since I don't see the thread in the list when I pause the program after the execution of the slot).
-
@Christian-Ehrlicher On Windows 10, I built the example using Qt Creator (based on 5.15.2, the installer does not propose a more recent version, strange) and like on Ubuntu version there's absolutely no problem at all : the event loop is stopped when quit() is called and will never EVER be started again.
What's wrong with the vcpkg version ??!!???? You will note that my github example was originally made for an UI bug with QTableView that manifests only with vcpkg on Windows 10 (but on Windows 8.1 it's the opposite: under Qt Creator there is a problem while with vcpkg there is no problem).
Is vcpkg not using the right configuration to build Qt ? or is the problem only related to 5.15.3 (which I don't think) ? this kind of problem is very annoying. I don't want to stop using vcpkg since I prefer using Visual Studio instead of Qt Creator (on Windows of course).
-
It works fine for me by accident since it's a timing issue in your code.
You got the signal to stop the thread and handle it in setKeepStressTesting(). But before this is done, QThread::quit() was called and all active eventloops were notified about it and exited. But then you call processEvents() again and start the eventloop again.
Use QThread::interrupt() and QThread::isInterruptionRequested() since this sets an internal QThread variable which prevents the restart of the eventloop handling.@Christian-Ehrlicher You know what's really strange ? I uninstalled Qt (with Qt5.15.2) and reintstalled it (with Qt5.15.2 and Qt6) and now I have the issue now on Qt Creator AND the UI bug (extra white space in the QTableView) that didn't exist before the reinstallation. WTF is going on with Qt on the Windows platform ???!!?? Huge palm face ! Epic fail reward !
-
It works fine for me by accident since it's a timing issue in your code.
You got the signal to stop the thread and handle it in setKeepStressTesting(). But before this is done, QThread::quit() was called and all active eventloops were notified about it and exited. But then you call processEvents() again and start the eventloop again.
Use QThread::interrupt() and QThread::isInterruptionRequested() since this sets an internal QThread variable which prevents the restart of the eventloop handling.@embeddedmz_2 let me quote Christian from earlier
@Christian-Ehrlicher said in Infinite wait when stopping QThread event loop and then calling wait:
It works fine for me by accident, since it's a timing issue in your code.
-
@embeddedmz_2 let me quote Christian from earlier
@Christian-Ehrlicher said in Infinite wait when stopping QThread event loop and then calling wait:
It works fine for me by accident, since it's a timing issue in your code.
@J-Hilk I don't think it's a timing issue since there's a for loop running on the stress test thread and with each iteration process events is called on the thread's dispatcher many times after quit() has been called on the QThread object.
and what surprises me is what I described in my previous post about reinstalling Qt on Windows and the return of the problem with the native environment (+ the UI bug). There's a serious quality problem of the Qt version on Windows.
-
@Christian-Ehrlicher @J-Hilk
On Windows :
5.15.2 (MSVC2019) => bug on the QTableView and on the event loop
5.15.1 (MSVC2019) => bug on the QTableView and on the event loop
5.15.0 (MSVC2019) => bug on the QTableView and on the event loop
5.12.11 (MSVC2017) => everything is fine !There's clearly a code regression that happened between 5.12.11 (MSVC2017) and 5.15.0 (MSVC2019).
I like Qt, that's why I put some effort in understanding these strange bugs.
5.12.11 (MSVC2017) : QTableWidget is rendered correctly + the event loop isn't restarted when processEvents is called :
-
bug reported here : https://bugreports.qt.io/browse/QTBUG-105207
-
bug reported here : https://bugreports.qt.io/browse/QTBUG-105207
@embeddedmz_2 seems like you found a bug, and not necessarily in Qt. But the culprit, like so often, is the manual call to processEvents.
-
@embeddedmz_2 seems like you found a bug, and not necessarily in Qt. But the culprit, like so often, is the manual call to processEvents.
@J-Hilk said in Infinite wait when stopping QThread event loop and then calling wait:
seems like you found a bug, and not necessarily in Qt. But the culprit, like so often, is the manual call to processEvents.
if your program behaves differently from one version of Qt to another, it is a bug in Qt.
-
@J-Hilk said in Infinite wait when stopping QThread event loop and then calling wait:
seems like you found a bug, and not necessarily in Qt. But the culprit, like so often, is the manual call to processEvents.
if your program behaves differently from one version of Qt to another, it is a bug in Qt.
@embeddedmz_2
Or, it is that you relied on certain behaviour you found in a previous version, or a different platform, and decided that was guaranteed behaviour, when it is not.I read the response from the Qt devs to your bug report. It seems to me that you are in such a situation.
Wouldn't it be more constructive for you to revisit how you are using
processEvents()to find a better way to achieve what you want, rather than announcing what is wrong in different Qt versions/platforms? Since they say they won't change behaviour for your case that would seem more practical to me. -
@J-Hilk said in Infinite wait when stopping QThread event loop and then calling wait:
seems like you found a bug, and not necessarily in Qt. But the culprit, like so often, is the manual call to processEvents.
if your program behaves differently from one version of Qt to another, it is a bug in Qt.
@embeddedmz_2 said in Infinite wait when stopping QThread event loop and then calling wait:
if your program behaves differently from one version of Qt to another, it is a bug in Qt.
Not necesserily...
