summaryrefslogtreecommitdiff
path: root/vcl/README.scheduler
AgeCommit message (Collapse)Author
2018-09-27Fix typosAndrea Gelmini
Change-Id: Icfe120db02a70d43e4120d1f4cbb2704640d3990 Reviewed-on: https://gerrit.libreoffice.org/59470 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-06-21merge GenericSolarMutex and SolarMutexNoel Grandin
Since nothing else is implementing the SolarMutex abstract class. Change-Id: I2a41254af3e9c7534033cdd0bece9dd8e0258b9d Reviewed-on: https://gerrit.libreoffice.org/56153 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-20WIN guarantee direct timeout handlingJan-Marek Glogowski
The code did acccount processing of an invaild timeout system message as a valid timeout event. Change-Id: I3c31f8b9cec592631b4089411163dadecffde816 Reviewed-on: https://gerrit.libreoffice.org/43529 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-16tdf#112076 OSX post timeout after shouldCloseWindowJan-Marek Glogowski
It seems that something filters application defined events when closing a window... DoYield expects a timeout event, which never arrives, stopping all redraw and generating a busy loop. Change-Id: Ic83468cceac7b967acaecf18b321178fc7565b94 Reviewed-on: https://gerrit.libreoffice.org/43381 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-13WIN fix redraw during window move and resizeJan-Marek Glogowski
During window move and resize, Windows spawns a nested message loop, blocking our direct processing. In this case we switch to timer messages for all timeouts. But if LO is busy with background jobs, the posted 0ms timer messages will block any system event processing, halting any updates until we're idle again. So for these cases we switch to the WM_TIMER based SetTimer timer. Change-Id: I854f4984d7c75d6829f82cda5cb4479967edce48 Reviewed-on: https://gerrit.libreoffice.org/43350 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-13WIN another system loop integration attemptJan-Marek Glogowski
This time we skip the intention to handle our Scheduler completely via the system event loop. Instead we basically guarantee to process a Scheduler event during each DoYield, if one is available. This way we won't block system events when busy in our event loop. Change-Id: I37094e61cbf928733151d9cc3299cdac76b3a5cd Reviewed-on: https://gerrit.libreoffice.org/43349 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-04Convert tick-based timer events to versioned onesJan-Marek Glogowski
Instead of storing the system ticks in the timer event message simply store a version. Moves the version handling code into a VersionedEvent class, inherited by WinSalTimer and AquaSalTimer. Change-Id: I5add85031d36b3424a26a9ef798294cbfb00b2e4 Reviewed-on: https://gerrit.libreoffice.org/42959 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-27Don't wait-yield non-main threads in the main threadJan-Marek Glogowski
This prevents blocking the main thread by a yielding non-main thread. The current solution is to wait on a condition, which is set by the main thread on wakeup. Change-Id: I8d680bb51a36ce1e0d3d4713d47d8e2ef93d7297 Reviewed-on: https://gerrit.libreoffice.org/42808 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-26Fix typosAndrea Gelmini
Change-Id: I9aaefa47399f35d563c1a4df364512dd29db41ce Reviewed-on: https://gerrit.libreoffice.org/42817 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-09-26Fix typosAndrea Gelmini
Change-Id: Id8f863963cb2f34d81f2ad82353caaa2d03d59be Reviewed-on: https://gerrit.libreoffice.org/42807 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-09-26tdf#112288 Clarify Reschedule implementationsJan-Marek Glogowski
Application::Reschedule(true) must just process all currently pending events and ignore all new events generated while processing them. In contrast to Scheduler::ProcessEventsToIdle, this way it can't busy-lock the application with background jobs. This way we also can drop nMaxEvents from the Windows backend. This limit was also never implemented on OSX and for the KDE4 backend it's actually impossible to handle single events, and a call to QAbstractEventDispatcher::processEvents works like this. Also changes various call sites to just process all pending events instead of some made up number of times. Change-Id: I1ab95df89b079cc8c6319a808194fe3127144d1c Reviewed-on: https://gerrit.libreoffice.org/42659 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-26WIN run main thread redirects ignoring SolarMutexJan-Marek Glogowski
This way we can drop all the special nReleased handling. Instead we use the same mechanism as on Mac, where we keep the lock, but disable it for the main thread. As a security measure we assert on duplicate redirects, which should not happen. As a result we can't use SendMessage on the main thread itself, which would normally just call the WinProc directly. This could be accomplished by converting the redirect bool into a counter, which should be safe, as no other thread could acquire the SolarMutex, as we don't release it. Change-Id: Icd87b3da37a2489f3cad2bc80215bf93fc41d388 Reviewed-on: https://gerrit.libreoffice.org/42583 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-22tdf#111994 WIN workaround PostMessage delaysJan-Marek Glogowski
Fixes the "Multiple timers in queue" assertion by effectively removing it. When debugging it became obvious, that PostMessage returns, even if the message was not yet added to the message queue. The assert happens, because we start the timer in the Scheduler before Invoke(), so it fires, if we block in Invoke(), and then reset the timer after Invoke, if there were changes to the Task list. In this case it fires during Invoke(), the message is added. We restart the timer, first by stopping it (we wait in DeleteTimerQueueTimer, to be sure the timer function has either finished or was not run). And the try to remove the message with PeekMessageW, which doesn't remove the posted message. Then the timer is restarted, and when the event is processed, we end up with an additional timer event, which was asserted. As a fix this adds a (microsecond) timestamp to the timer message, which is validated in the WinProc function. So if we stop the timer too fast, the event is ignored based on the timestamp. And while at it, the patch moves timer related variables from SalData into WinSalTimer. Change-Id: Ib840a421e8bd040d40f39473e1d44491e5b332bd Reviewed-on: https://gerrit.libreoffice.org/42575 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-22Fix typosAndrea Gelmini
Change-Id: I51700733fda3a08570085ed6745961cd1680eabd Reviewed-on: https://gerrit.libreoffice.org/42588 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-09-21Workaround static Task destruction errorJan-Marek Glogowski
A task has to get the SchedulerLock to remove itself from the Scheduler list. This doesn't work, if the Task is static, as the static Scheduler might be destroyed earlier. In this case we fail with the following backtrace: #0 SchedulerMutex::acquire #1 Task::~Task #2 __run_exit_handlers Thanks to Michael Stahl to catching this backtrace. As a workaround this marks static tasks, so they ignore the SchedulerMutex in the destructor, We also mark all scheduled Tasks as "static" in DeInitScheduler, as their cleanup was already done. In the end all Tasks should be removed from static objects. Change-Id: I38be3206378b9449193efaccbc96896ac8de9478 Reviewed-on: https://gerrit.libreoffice.org/42574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-21tdf#99784 OSX run GUI stuff in the main threadJan-Marek Glogowski
The extension manager starts dialogs from its own thread. But the OSX backend currently doesn't defer these calls to the main thread. This implements the deference by running the called function in the main thread, using a code ^Block, and returning the result via a SalYieldMutex member. Change-Id: Id8977991e3eda91da27c23d8021e028d4f4cefe5 Reviewed-on: https://gerrit.libreoffice.org/42448 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-08-22OSX fix updates during resizeJan-Marek Glogowski
While resizing MacOS suspends the NSDefaultRunLoopMode. So in this caae we can't post to the system event loop, but must use timers to restart ourself. Since the timer itself is scheduled on the NSEventTrackingRunLoopMode it' also triggers on resize events. There is still some minor glitch: when resizing too fast some part of LibreOffice isn't painted, while the left mouse button is down. Since there isn't any layouting triggered by the mouse up, there has to be an other inconsistency. Change-Id: I3ccba78bd23ec8526f21e7b93b027f3d3279f901
2017-08-17Fix typosAndrea Gelmini
Change-Id: Iaa9c0aea3ea1a239e378bd714ba335f91bb1faf3 Reviewed-on: https://gerrit.libreoffice.org/41194 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-08-04Add VCL scheduler documentationJan-Marek Glogowski
Change-Id: Ifb2332b6d3c8bf472c684d3a79c861cc9035d246
generated by cgit (git 2.34.1) at 2025-01-19 21:10:10 +0000