10bc093d4f
Current implementation of QProgressDialog always calls QCoreApplication::processEvents() when the user calls QProgressDialog::setValue() if the PD is modal. For most cases this is fine, but when using a Qt::WindowModal PD with setValue() connected to a signal in another thread using Qt::QueuedConnection a reentrancy issue is present if setValue() is triggered too frequently as the execution of its previous call may not have finished. If this happens too many times in a row a stack overflow will occur. Current documentation notes this potential issue but offers no way it avoid it while still using QProgressDialog (user must implement a custom dialog) without resorting to using Qt::BlockingQueuedConnection, which unnecessarily reduces performance. Introduces the boolean reentrancy guard "processingEvents" that is checked before calling QCoreApplication::processEvents() in a modal PD when setValue() is used. It is set before the first call to processEvents() and cleared after that call returns. This ensures that only one invocation of processEvents() is possible from within setValue() at a time, and thereby minimizes iterations of the main event loop and eliminates the aforementioned stack overflow condition. See - https://forum.qt.io/topic/118292/ Fixes: QTBUG-10561 Pick-to: 5.15 Change-Id: Ifa9b91cbb66881981356954ead0906bdc91fab60 Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch> |
||
---|---|---|
.. | ||
cmake | ||
concurrent | ||
corelib | ||
dbus | ||
gui | ||
guiapplauncher | ||
installed_cmake | ||
network | ||
opengl | ||
other | ||
printsupport | ||
shared | ||
sql | ||
testlib | ||
tools | ||
widgets | ||
xml | ||
.prev_CMakeLists.txt | ||
auto.pro | ||
CMakeLists.txt | ||
network-settings.h |