Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
4.6.2, 5.5.0
-
In Windows but seems to be a common problem
-
13
-
Qt6_Foundation_ Sprint 9, Qt6_Foundation_ Sprint 10
Description
When QFutureWatcher::pause is called, the future is correctly paused, but the paused signal is not emited inmediatly. Moreover, the signal is emitted after the future is resumed.
The problem seems to be in QFutureWatcherBase::event
When a pause event is processed, because the current state is paused, the event is appended to pendingCallOutEvents
When a resume event is processed, the resume event is sent and then all events from pendingCallOutEvents. Thats why resume signal is received and then the pause signal.
The pause event should be sent despite of the current state is paused.
Taking the attached example, this is the output produced:
"12:06:53.259" Fwl::onResumed
"12:06:53.259" Fwl::onProgressRangeChanged
"12:06:53.259" Fwl::onProgressValueChanged
"12:06:53.259" Fwl::onPaused
"12:06:53.259" Fwl::onResumed
"12:06:54.261" Fwl::onProgressValueChanged
"12:06:57.265" Fwl::onProgressValueChanged
"12:06:59.268" Fwl::onProgressValueChanged
"12:07:00.269" Fwl::onProgressValueChanged
"12:07:02.272" Fwl::onProgressValueChanged
"12:07:04.275" Fwl::onProgressValueChanged
"12:07:04.275" Fwl::onFinished
Note that Paused and Resumed arrived at the same time, and in the code, there is a 5 sec delay between both
f.pause();
PauseFunction(5);
f.resume();
It is also noticeable if you put a breakpoint on the following functions:
Fwl::onPaused()
Fwl::onResumed()
Fwl::resume()
Fwl::pause()
You will note that pause is called, and onPaused is not, after that, resume is called, and then, onResumed is called and after that onPaused is called.
Attachments
Issue Links
- relates to
-
QTBUG-61928 Make a decision for asynchronous APIs
- Closed