SchedulerRequirements ===================== // please don't remove the //word: comments [grid="all"] `------------`----------------------- *State* _Idea_ *Date* _Mi 09 Jan 2013 12:04:03 CET_ *Proposed by* Ichthyostega ------------------------------------- ******************************************************************************** .Abstract The rendering and playback subsystem relies on a Scheduler component to invoke individual frame rendering and resource fetching jobs. This RfC summarises the general assumptions and requirements other parts of the application are relying on ******************************************************************************** Define the core properties and requirements of the Scheduler. Description ----------- //description: add a detailed description: The *Scheduler* is responsible for getting the individual _render jobs_ to run. The basic idea is that individual render jobs _should never block_ -- and thus the calculation of a single frame might be split into several atomic jobs, including resource fetching. Together with the data exchange protocol defined for the `OutputSlot`, and the requirements of storage management (especially releasing of superseded render nodes -> `Fixture` storage), this leads to certain requirements to be ensured by the scheduler: ordering of jobs:: the scheduler has to ensure all prerequisites of a given job are met job time window:: when it is not possible to run a job within the defined target time window, it must not be run any more but rather be marked as failure failure propagation:: when a job fails, either due to an job internal error, or by timing glitch, any dependent jobs need to receive that failure state guaranteed execution:: some jobs are marked as ``ensure run''. These need to run reliable, even when prerequisite jobs fail -- and this failure state needs to be propagated detecting termination ~~~~~~~~~~~~~~~~~~~~~ The way other parts of the system are built, requires us to obtain a guaranteed knowledge of some job's termination. It is possible to obtain that knowledge with some limited delay, but it needs to be absolutely reliable (violations leading to segfault). The requirements stated above assume this can be achieved through _jobs with guaranteed execution._ Alternatively we could consider installing specific callbacks -- in this case the scheduler itself has to _guarantee the invocation of these callbacks,_ even if the corresponding job fails or is never invoked. It doesn't seem like there is any other option. Tasks ~~~~~ // List what needs to be done to implement this Proposal: // * first step ([green]#✔ done#) * define the job interface [yellow-background]#WIP# * define a protocol for job state handling [red yellow-background]#TBD# * define the representation of dependencies and the notifications in practice [red yellow-background]#TBD# * verify the proposed requirements by an scheduler implementation sketch [red yellow-background]#TBD# /////// Discussion ~~~~~~~~~~ Pros ^^^^ // add a fact list/enumeration which make this suitable: // * foo // * bar ... Cons ^^^^ // fact list of the known/considered bad implications: Alternatives ^^^^^^^^^^^^ //alternatives: explain alternatives and tell why they are not viable: ///////// Rationale --------- //rationale: Give a concise summary why it should be done *this* way: [red yellow-background]#to be written# //Conclusion //---------- //conclusion: When approbate (this proposal becomes a Final) // write some conclusions about its process: Comments -------- //comments: append below //endof_comments: '''' Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]