Infinite wait when stopping QThread event loop and then calling wait
-
@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...
