20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
m
→Future Changes (post 3.2): updates
m (→Future Changes (post 3.2): updates) |
|||
| Line 105: | Line 105: | ||
== 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: | ||
* 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). | |||
* 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() | |||
* 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. | |||
* each Subsystem that provides Nasal APIs, needs to implement the bind/unbind APIs to register/release Nasal APIs | |||
* 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) | |||
* getting rid of singletons could help simplify the init process | * getting rid of singletons could help simplify the init process | ||
* fixing up subsystems with non-default ctors: | * fixing up subsystems with non-default ctors: | ||
| Line 114: | Line 120: | ||
** events | ** events | ||
** materials | ** materials | ||
* there are a few subsystems that are intended to remain PERSISTENT per session, e.g. terragear, time, lighting, events - those should probably be put into a dedicated SGSubsystemGroup that isn't subject to reset/re-init at all, e.g. outside the actual subsystem_mgr, or maybe using a new GroupType ? | * there are a few subsystems that are intended to remain PERSISTENT per session, e.g. terragear, time, lighting, events - those should probably be put into a dedicated SGSubsystemGroup that isn't subject to reset/re-init at all, e.g. outside the actual subsystem_mgr, or maybe using a new GroupType ? | ||
* fgCreateSubsystems() in fg_init.cxx and subsystemFactory.cxx are now overlapping in functionality, and we've seen some inconsistencies here that may further complicate matters[https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381]. It would make sense to get rid of fgCreateSubsystems() and move this into scripting space by using the add-subsystem fgcommand APIs (have this kinda working in the [[Initializing Nasal early]] branch, [https://gitorious.org/fg/canvas-hackers-fgdata/source/ad77a4db14a00103f30c9fb219d3dab72e479ca3:Boot/default.boot using a boot script]). | * fgCreateSubsystems() in fg_init.cxx and subsystemFactory.cxx are now overlapping in functionality, and we've seen some inconsistencies here that may further complicate matters[https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381]. It would make sense to get rid of fgCreateSubsystems() and move this into scripting space by using the add-subsystem fgcommand APIs (have this kinda working in the [[Initializing Nasal early]] branch, [https://gitorious.org/fg/canvas-hackers-fgdata/source/ad77a4db14a00103f30c9fb219d3dab72e479ca3:Boot/default.boot using a boot script]). | ||