summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorJan-Marek Glogowski <glogow@fbihome.de>2018-08-24 08:05:26 +0200
committerCaolán McNamara <caolanm@redhat.com>2018-08-29 16:45:42 +0200
commit20e46a6ca5b62f7177f799eae9e0f26e659fd03b (patch)
treeb0b0e446ded905d79794177b1f5dc6a92fd74a20 /include
parentdb55d2a53af04a88ba070e619760f573e89e12fd (diff)
tdf#119458 reorganize sw background Idle handling
This is the squashed version of the following commits: - ce68889678bc tdf#119458 always start the SwDocIdle - 107f0e6dba57 tdf#119458 fix sw background Idle state handling - 771544544ee1 tdf#119458 fix sw background Idle unblocking - 3bd8316718fd tdf#119458 just wakeup Scheduler on active Idle While the first commit was really wrong, the third is just an optimization to prevent unnecessary wakeups and Idle task interrups from new calls to StartIdling(). The 4th one contains the reset of the Idle state on run, which was probably the main origin of the problem and allows to wake up the Scheduler without moving the Task to the end of the queue. Starting the SwDocIdle in StartIdeling() just reintroduces the bug fixed in commit 401cba4c20fb ("tdf#116370 cleanup Writer idle job handing"), so trading one bug for the other. For the real solution we have to handle two states: 1. The SwDocIdle being active 2. The SwDocIdle being blocked For the first state we can just use the active state of the Idle itself. Since it's not a AutoIdle, it will be turned of, if invoked. Either some Idle handler will want to be run it again or some other thread might start it again, if needed. Since we're now tracking the wanted Idle state via the active task flag, we can drop the explicit mbStartIdleTimer handling. As a result of the first change, we can't stop the Idle anymore when blocking it. But the Idle itself checks its ready state via IsDocIdle() in its UpdateMinPeriod function, so we have to add the blocking state to IsDocIdle(). But we can't handle the correct state when blocking via a tasks mbActive bool, as this also schedules the task and starts the scheduler timer. So reintroduce a bool for the unblock state. This should prevent fdo#73165, which I couldn't reproduce, but just to be sure. More importantly this patch resets the m_bStartOnUnblock when the Idle job actually runs. This run should already determinates if more Idle work needs to be done, and others can still call BeginIdling() to ensure further processing. Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/59536 (cherry picked from commit ce68889678bca3b51c258452f7bfdd21982e4a0d) Reviewed-on: https://gerrit.libreoffice.org/59586 (cherry picked from commit 107f0e6dba57a5b27366a35a5cdb184079546df0) Reviewed-on: https://gerrit.libreoffice.org/59692 (cherry picked from commit 771544544ee13ec98961f93b5313a7d2e29429cd) Reviewed-on: https://gerrit.libreoffice.org/59730 (cherry picked from commit 3bd8316718fdfed454c01a9c4ae6af6beb34437d) Change-Id: I2d4328f31644017b09786ff4cba45cf7643f0a4b (cherry picked from commit f1fb30cf43eda45137ab96177238a29c3725789d) Reviewed-on: https://gerrit.libreoffice.org/59757 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
Diffstat (limited to 'include')
-rw-r--r--include/vcl/scheduler.hxx12
1 files changed, 12 insertions, 0 deletions
diff --git a/include/vcl/scheduler.hxx b/include/vcl/scheduler.hxx
index ac429ed33b09..6233d134a8ed 100644
--- a/include/vcl/scheduler.hxx
+++ b/include/vcl/scheduler.hxx
@@ -65,6 +65,18 @@ public:
*/
static void ProcessEventsToIdle();
+ /**
+ * Wakes up the scheduler
+ *
+ * This doesn't handle any events! It just ensures the Scheduler is run as
+ * soon as possible by forcing the Scheduler timer to fire.
+ *
+ * Can be used for complex UpdateMinPeriod function, where the task is
+ * actually active but not ready and we want to skip the Task::Start()
+ * queue append for faster reaction.
+ */
+ static void Wakeup();
+
/// Control the deterministic mode. In this mode, two subsequent runs of
/// LibreOffice fire about the same amount idles.
static void SetDeterministicMode(bool bDeterministic);