Avoid deadlock with two consecutive suspended notification
According to our Android app test, sometimes we will receive two consecutive app suspended notifications. In the second app suspended notification QWindowSystemInterface::flushWindowSystemEvents() will deadlock due to the fact that the event dispatcher has been stopped in the first app suspended notification. This patch will simply return if we found the event dispatcher has been stopped in the beginning of app suspended notification. Change-Id: I15fa4a6a118510b866ff16061862f4bb8360cc9b Reviewed-by: BogDan Vatra <bogdan@kde.org>
This commit is contained in:
parent
a9bb1c63dc
commit
8c0ef140b3
@ -593,6 +593,13 @@ static void updateApplicationState(JNIEnv */*env*/, jobject /*thiz*/, jint state
|
||||
return;
|
||||
|
||||
if (state <= Qt::ApplicationInactive) {
|
||||
// NOTE: sometimes we will receive two consecutive suspended notifications,
|
||||
// In the second suspended notification, QWindowSystemInterface::flushWindowSystemEvents()
|
||||
// will deadlock since the dispatcher has been stopped in the first suspended notification.
|
||||
// To avoid the deadlock we simply return if we found the event dispatcher has been stopped.
|
||||
if (QAndroidEventDispatcherStopper::instance()->stopped())
|
||||
return;
|
||||
|
||||
// Don't send timers and sockets events anymore if we are going to hide all windows
|
||||
QAndroidEventDispatcherStopper::instance()->goingToStop(true);
|
||||
QCoreApplication::processEvents();
|
||||
|
Loading…
Reference in New Issue
Block a user