20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
→Future Changes (post 3.2)
m (→Future Changes (post 3.2): updates) |
|||
| Line 104: | Line 104: | ||
== Future Changes (post 3.2) == | == Future Changes (post 3.2) == | ||
Based on experimenting with [[Initializing Nasal early]] and [[FGCanvas]], here's some feedback to hopefully further simplify the whole process and make it more flexible in the future: | Based on experimenting with [[Initializing Nasal early]] and [[FGCanvas]], here's some feedback to hopefully further simplify the whole process and make it more flexible in the future (comments welcome!): | ||
* making sure that all subsystems actually implement SGSubsystem would be helpful,especially those that are separately handled by reset/re-init (e.g. FGInterpolator, NavDataCache) - see Tom's commit at [https://gitorious.org/fg/flightgear/commit/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382] | * making sure that all subsystems actually implement SGSubsystem would be helpful,especially those that are separately handled by reset/re-init (e.g. FGInterpolator, NavDataCache) - see Tom's commit at [https://gitorious.org/fg/flightgear/commit/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382] | ||
* we have several corner-cases of FGGlobals fields that are separately managed by logic in fg_init.cxx: we should probably even consider turning the SGPropertyNode root in globals.cxx into a wrapped SGSubsystem - because the reset/re-init logic explicitly contains stuff to deal with the property tree: Whenever a "member" needs to be explicitly handled to support reset/re-init, we should consider wrapping them in a separate SGSubsystem class so that we can encapsulate the reset/re-init logic there, instead of doing that separately in fg_init.cxx, where all the important subsystem-specific logic is kept separate from the actual subsystem (not maintenance-friendly). | * we have several corner-cases of FGGlobals fields that are separately managed by logic in fg_init.cxx: we should probably even consider turning the SGPropertyNode root in globals.cxx into a wrapped SGSubsystem - because the reset/re-init logic explicitly contains stuff to deal with the property tree: Whenever a "member" needs to be explicitly handled to support reset/re-init, we should consider wrapping them in a separate SGSubsystem class so that we can encapsulate the reset/re-init logic there, instead of doing that separately in fg_init.cxx, where all the important subsystem-specific logic is kept separate from the actual subsystem (not maintenance-friendly). | ||
* lots of problems result from the ambiguity of resets vs. re-init/repositioning, it would make sense to extend SGSubsystem accordingly and expose two virtual methods to handle reset and repositioning explicitly per object, and not separately-we'd want to extend SGSubsystemGroup accordingly, to ensure it can delegate events to each member | * lots of problems result from the ambiguity of resets vs. re-init/repositioning, it would make sense to extend SGSubsystem accordingly and expose two virtual methods to handle reset and repositioning explicitly per object, and not separately-we'd want to extend SGSubsystemGroup accordingly, to ensure it can delegate events to each member | ||
* Nasal is currently being dealt with separately, and quite frankly, it doesn't belong into the same SGSubsystemMgr - we'd be MUCH better off by adding a simple SGSharedPtr<FGNasalSys> to globals.hxx with a getter. That way, we can easily allocate & initialize Nasal very early, without having to manually call nasal->init() in fgPostInitSubsystems() | * Nasal is currently being dealt with separately, and quite frankly, it doesn't belong into the same SGSubsystemMgr - we'd be MUCH better off by adding a simple SGSharedPtr<FGNasalSys> to globals.hxx with a getter. That way, we can easily allocate & initialize Nasal very early, without having to manually call nasal->init() in fgPostInitSubsystems() | ||
* Given the '''add-subsystem'''/'''remove-subsystem''' fgcommands/APIs, we can no longer afford having '''initNasal''FOO''()''' code in FGNasalSys::init() that depends on other subsystems being present. Subsystem-specific APIs must never be unconditionally added, they need to be added/released (managed) by the underlying subsystem itself, or things will break inevitably. | * init order is currently kinda fragile, it'd make sense to internally use each subsystem's bind/unbind and postinit() methods to ensure that cleanup is handled there, and not in fgPostInitSubsystems() or fgStartNewReset(), each run-level/group would then internally manage things: | ||
** Allocating Nasal as early as possible is a pre-requisite for using bind() to add Nasal/cppbind bindings, because the instance pointer must be valid obviously (i.e. have _context/_globals set up already) | |||
** each Subsystem that provides Nasal APIs, needs to implement the bind/unbind APIs to register/release Nasal APIs | |||
** Given the '''add-subsystem'''/'''remove-subsystem''' fgcommands/APIs, we can no longer afford having '''initNasal''FOO''()''' code in FGNasalSys::init() that depends on other subsystems being present. Subsystem-specific APIs must never be unconditionally added, they need to be added/released (managed) by the underlying subsystem itself, or things will break inevitably. | |||
* getting rid of singletons could help simplify the init process | * getting rid of singletons could help simplify the init process | ||
* Once we use a PropertyObject<int> for '''idle_state''' in main.cxx, we can easily use Nasal to implement the whole splash screen loop in '''fgIdleFunction()''' using a single listener. | |||
* fixing up subsystems with non-default ctors: | * fixing up subsystems with non-default ctors: | ||
** performance-monitor | ** performance-monitor | ||
| Line 130: | Line 133: | ||
** WORLD: ai, atc, traffic | ** WORLD: ai, atc, traffic | ||
** AIRCRAFT: flight, controls, systems, instrumentation, hud, cockpit-displays, replay, history, autopilot, route-manager | ** AIRCRAFT: flight, controls, systems, instrumentation, hud, cockpit-displays, replay, history, autopilot, route-manager | ||
[[Category:Developer Plans]] | [[Category:Developer Plans]] | ||