Development/LHM LiMux/Main Loop

= Main Loop =
 * Analysis - parallelizable!
 * Understand model of glib idle main loop.
 * Understand current LibreOffice idle main loop implementation and distill corresponding scheduling strategy.
 * Clarify which scheduling strategy is desired finally and distill required abstractions (e.g. dependencies, priorities, time slots, \u2026)
 * Classify existing calls to scheduling interface according to required abstractions (see above).
 * Implementation - step-by-step where each step yields a running system!
 * Tune existing scheduling interfaces if sensible.
 * Formal extension of the scheduling interface to take into account newly required abstractions.
 * Replace existing schedule by new one.
 * Make actually use of new scheduling strategy.
 * Fine-tuning of abstraction parameters.



Current matter of affair LO
The following graphic shows the cycle of the main loop:



Class /core/vcl/source/app/timer.cxx:
Git

Timers used at the moment:
Explanation: special cases External dependency: Timeout stems from external source, i.e. not changeable in the first api iteration. Git

dependencies between timers:

 * include/svx/svdpntv.hxx(aComeBackIdle) --> svx/source/svdraw/svdpntv.cxx (aComeBackIdle.Start/Stop ) --> chart2/source/controller/drawinglayer/DrawViewWrapper.cxx (aComeBackIdle.Stop )

Inherited Timers:
Git

Current matter of affair GLib

 * Glib uses Priority Scheduling
 * Dependencys are resolved with inherited priorities
 * The Timer has a single parent, and multiple childs
 * If the timer has "no" parent, the parent variable points to itself
 * If the timer has "no" childs, the variable is null
 * If a new timer is created out of another timer it gets the same priority as its father
 * No Starvation
 * No Deadlocks
 * Small Numbers are high priorities, higher Numbers are lower priorities

Task Breakdown

 * Change list to std::list

Q&A

 * Identify the hot-spot where events are announced.
 * So we found a class in vcl/source/app/timer.cxx which looks kind of interesting.
 * The header file, too.
 * For example we read the vcl/source/gdi/animate.cxx where the timer is implemented, and it looks like there are only two methods at the moment, where data can be defined. The SetTimout(...) method and the SetTimeoutHdl(...) method.
 * Further Questions:
 * Many timers per event? (every picture one timer, or all pictures one timer) - No One Timer per event
 * LINK? - Method: IMPL_LINK_NOARG(, Hdl) called
 * SetTimeout(number)? (who set the numbers)
 * What is the current scheduling strategy?
 * Suspicion: optimistic with restart on demand - No real strategy, linear work off
 * What is our desired goal scheduling strategy?
 * Suspicion: dependencies and priorities - Yup that's correct
 * Is an atomic interface for (current) SetTimout(...) / SetTimeoutHdl(...) interface feasible and desirable?
 * How are idle events (timers) actually set up?
 * Suspicion: by subclassing and by dynamic invocation - One parent (if no parent, it's the timer itself), multiple children timer -> parent_priority == children_priority
 * Are current timeouts static values or dynamically contrieved? - some are statc some dynamic, glib priorities are static
 * Is a global centralized declarative description for abstraction parameters (dependencies, priorities) feasible and desirable?