20,741
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
m
→Ideas
mNo edit summary |
m (→Ideas) |
||
| Line 24: | Line 24: | ||
As I say, I'm still trying to decide what approach is cleaner; the run-level concept is just one property, and nicely encapsulates the hierarchy of subsystems (if you're switching to level 8, all lower levels must already be initialized). But having names and separate flags makes the actual dependency clearer: 'this script depends on the aircraft subsystems' or 'this script depends on the environmental subsystems'. I guess it partly depends how complex the dependencies for any given script are in practice - hopefully they're actually quite simple.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03386.html |title=Subsystem run-levels|author=James Turner |date=17 April 2006 }}</ref>}} | As I say, I'm still trying to decide what approach is cleaner; the run-level concept is just one property, and nicely encapsulates the hierarchy of subsystems (if you're switching to level 8, all lower levels must already be initialized). But having names and separate flags makes the actual dependency clearer: 'this script depends on the aircraft subsystems' or 'this script depends on the environmental subsystems'. I guess it partly depends how complex the dependencies for any given script are in practice - hopefully they're actually quite simple.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03386.html |title=Subsystem run-levels|author=James Turner |date=17 April 2006 }}</ref>}} | ||
== Properties to the Rescue == | |||
It is worth noting that all startup arguments implemented via properties (--prop:) can be also trivially supported at runtime using listeners or conventional polling, i.e. supporting runtime changes of these properties is comparatively simple and a well-understood task. | |||
So looking at the code in fg_init.cxx, the major problem is indeed all the static, hard coded, initialization code which assumes a statically defined initialization order. | |||
In other words, our problem is that we have routines which are sequentially called and which call each other. These hard coded init assumptions are exactly what makes runtime re-initialization so difficult and non-deterministic currently (see [[FlightGear Sessions]]. Once we start using properties and listeners to implement '''all''' existing startup arguments, we would ''automatically'' have a fully runtime-configurable system, because callbacks would never be invoked directly at the C++ level, but instead be indirectly invoked by setting properties. | |||
For example, at the moment we have code in [https://gitorious.org/fg/flightgear/blobs/next/src/Main/options.cxx#line1282 $FG_SRC/Main/options.cxx] which maps the startup parameters to callbacks, which in turn call custom parsers to further process these arguments. What is really needed is a single SGPropertyChangeListener interface class which wraps the concept of a startup/runtime argument, so that all the argument-related code is wrapped inside a single helper class, instead of being spread over many different places in legacy procedural code. | |||
Furthermore, it is worth noting that we can significantly reduce the complexity of the options/init handling code by moving code to Nasal space and initializing the Nasal interpreter earlier. This applies especially to all the legacy C++ code setting up property defaults, i.e. see [https://gitorious.org/fg/flightgear/blobs/next/src/Main/options.cxx#line115]. Most of this would be better dealt with in Nasal space. | |||
<references/> | <references/> | ||