Infinite wait when stopping QThread event loop and then calling wait
-
wrote on 26 Jul 2022, 07:12 last edited by embeddedmz_2
@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.wrote on 26 Jul 2022, 10:44 last edited by embeddedmz_2@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.
wrote on 26 Jul 2022, 10:58 last edited by embeddedmz_2@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.
-
wrote on 26 Jul 2022, 15:52 last edited by embeddedmz_2
@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 :
-
wrote on 26 Jul 2022, 16:31 last edited by
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.
wrote on 27 Jul 2022, 08:58 last edited by embeddedmz_2@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.
wrote on 27 Jul 2022, 09:05 last edited by@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...
21/30