Lumiera is envisioned as a heavyweight yet coherent »Application« — not so much as platform, framework or operating system. And, in accordance with this focus, we place no emphasis on possible configuration changes and state transitions within the running application as a whole. And, while in fact it is possible to close and load a new Session, most of the time we assume the application just to be “up and running” — all required services to be available and interfaces to be accessible. Without doubt, these are simplifications, but serve us well to cut down complexity — yet still there needs to be one dedicated realm to deal with these specific concerns of configuration, dependency and lifecyle.
The Application Realm
So we treat all these concerns within a small and self contained structure, clearly set apart from all the other layers, services and subsystems. This dedicated Application Realm is organised around the “Application main object”.(1) It serves the purpose of pulling up and tearing down the application in a controlled fashion. And additionally, it provides the Interface and Config core services. The act of building or tearing down this core realm and main object is what creates the Lifecycle of the application. This is a succession of “lifecycle phases” — and almost all activities happen within the operational phase, when everything is “up and running” or “just available”.
Subsystems
However, initially the application needs to be brought up, and at the end, all parts need to be unwound cleanly. To organise this process, we identify a limited number of Subsystems within the Application, which are more or less independent. Each Subsystem is self contained and groups some other parts and services, which typically work together and may be mutually dependent. These subsystems represent a grouping, applied for the purpose of starting and stopping the application in a regular way; they rather do not correspond 1:1 to a layer, an interface, a class or a plugin. As a matter of fact, they are rather irrelevant outside the mentioned »Application realm«. A subsystem may depend on other subsystems, which comprises a clear startup- and shutdown-ordering. However, once the application is in normal operational mode, the subsystems turn into a passive, guarding and managing role; the activities relevant for the application’s purpose rather rely on components, interfaces, services, all aggregated into the three Layers »Stage«, »Steam« and »Vault«.
We expect the following subsystems to be built eventually:
Engine, Session, PlayOut, GUI, Script runner, Renderfarm node.
Organisation of Subsystems
Not all subsystems need to be started for any use of the application. A script-driven use, or a renderfarm node does not need a GUI. So there is an overall global operation mode of the application, controlled through the launching options, and determined during the startup phase. It is the responsibility of the Application main object to pull up required functionality, which in turn might result in pulling up further subsystems as dependencies.
Subsystems are defined by implementing the interface lumiera::Subsys, which acts
as façade to conduct the lifecycle, find out about dependencies and shut down
the subsystem in the end. So this interface, together with the Subsystem Runner,
define a lifecycle protocol; each subsystem is free to implement this as it
sees fit. Typically, this façade will load plugins, register and provide further
business interfaces, and especially set up the Layer separation interfaces
which canalise any communication going on between the layers.
The GUI Façade is special, while in compliance with this protocol. The actual
UI is loaded from a plug-in at runtime,(2)
and so the implementation of this façade needs to reside in the application core
realm; it will start a GuiRunner to load and activate the GUI plug-in, which
then in turn has to open the public GUI Notification façade. The latter is
one of the Layer separation interfaces and comprises the actual way for the
lower layers to activate and interact with the user interface.
Parallelism
Actually this scheme builds on the assumption that starting each subsystem will not block the overall start/main/shutdown thread. Any subsystem is supposed to spawn its own control/event threads if necessary. The Lumiera application works fundamentally asynchronous. The user interface operates single threaded, in accordance to long established best practices of UI programming. However, any user interaction is translated into commands, sent down into the session and handled there one by one. The result of processing such commands will be pushed back up into the UI later and detached from the immediate interaction. Likewise, the re-rendering caused by changes in the session is carried out within the engine independently, relying on worker jobs and a thread pool.
Initialisation and Lifecycle
After some discussion,(3) the design leaned toward loosely coupled parts and a formal lifecycle; which saves us from investigating and coding up the various interdependencies explicitly. Rather, the parts of the application have to comply to Lifecycle Phases, and each part has to care for its own state transitions, invoked through lifecycle callbacks. We can distinguish two distinct models how to deal with lifecycle, and both are equally acceptable:
-
Assuming that operations happen in response to some client’s request, this activation should go through a service interface. Interfaces can be opened and closed in Lumiera, and this is accomplished by hooking them up below some subsystem.
-
However, some parts carry out continuous activities, and in that case a lifecycle hook should be registered, to limit activities to the appropriate lifecycle phase.
Application Start
-
some fundamental language-level facilities will be prepared during static initialisation. At some point, execution enters
main(argc,arvv). -
AppState::init()brings up the plugin loader and opens the config-interface. -
…followed by triggering ON_GLOBAL_INIT
-
the main thread then pulls up the subsystems (
AppState::maybeStart(subsystem)), according to the command line options. -
within each subsystem, façade interfaces will be opened through the interface/plug-in system.
-
At this point, the GUI plug-in is loaded and launched, the windows created, the UI event loop starts and the application becomes live.
-
shutdown or failure of any given subsystem initiates the shutdown sequence by requesting all other running subsystems to terminate. In the typical case, the UI subsystem will trigger this shutdown sequence, in response to closing the main window.
-
there is an ON_GLOBAL_SHUTDOWN event, which can be used for normal cleanup; In case of an emergency exit, the ON_EMERGENCY_EXIT event is triggered alternatively.
-
the AppState destructor tears down the core systems (config-interface and pluginloader).
-
we establish a policy to prohibit any non-local and non-trivial activities during the tear-down phase after leaving the
main()function.