13,212
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
Commit and source link templates and ticket templates instead of explicit URLs; Moving up an image
m (→Remaining Issues: http://sourceforge.net/p/flightgear/mailman/message/34483199/) |
(Commit and source link templates and ticket templates instead of explicit URLs; Moving up an image) |
||
| Line 10: | Line 10: | ||
{{Portability Navbar}} | {{Portability Navbar}} | ||
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode.]] | |||
: ''See also [[Initializing Nasal early]], [[Aircraft Center]] and [[FGCanvas]].'' | |||
Scheme agreed by James & Thorsten at FSWeekend 2012 to fix reset / re-init weirdness. | |||
== Motivation == | == Motivation == | ||
* Re-init of all subsystems doesn't work, because many subsystems don't support it. (There's an {{Issue|419}} open bug about this in the tracker). Instead we have 'reset', which does some special operations, but is different logic from normal startup. This leads to bugs when the reset behaviour differs to a fresh start. | * Re-init of all subsystems doesn't work, because many subsystems don't support it. (There's an {{Issue|419}} open bug about this in the tracker). Instead we have 'reset', which does some special operations, but is different logic from normal startup. This leads to bugs when the reset behaviour differs to a fresh start. | ||
* JSBSim has issues with resets since it doesn't read simulation state each frame - this is why you can't resume flying from a recording / replay for JSBSim aircraft. | * JSBSim has issues with resets since it doesn't read simulation state each frame - this is why you can't resume flying from a recording / replay for JSBSim aircraft. | ||
| Line 40: | Line 39: | ||
== Status / related Commits (02/2015) == | == Status / related Commits (02/2015) == | ||
{{FGCquote | {{FGCquote | ||
|We have already cleaned up a lot of subsystem / initialization things over the past year - and more things are planned. Eventually, I hope we can just recreate an FDM at any time ("out of thin air"... ;-) ) with arbitrary initial settings. | |We have already cleaned up a lot of subsystem / initialization things over the past year - and more things are planned. Eventually, I hope we can just recreate an FDM at any time ("out of thin air"... ;-) ) with arbitrary initial settings. | ||
| Line 68: | Line 66: | ||
James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. | James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. | ||
See: {{flightgear commit|881df711}} | |||
See: | |||
<pre> | <pre> | ||
2013-11-12 23:36 James Turner Reset: changes for SGSubsystem ownership. | 2013-11-12 23:36 James Turner Reset: changes for SGSubsystem ownership. | ||
| Line 86: | Line 83: | ||
</pre> | </pre> | ||
* {{flightgear commit|081240c4dad0076d9e0deb0cde21bee4dbd7629a|t=reset scenarios on sim-reset}} | |||
* | * {{flightgear commit|07e9b48344f9fce117f11e7f6a8c78c4932d9ee0|t=Preserve current view on reset/reinit/reposition}} | ||
* | * {{flightgear commit|8608a480736651999c5ea31a489343ee097ee915|t=Initial work on dynamic subsystem creation}} | ||
* | |||
== Remaining Issues == | == Remaining Issues == | ||
: ''See also {{Issue|1702}}'' | |||
* http://sourceforge.net/p/flightgear/mailman/message/34483199/ | * http://sourceforge.net/p/flightgear/mailman/message/34483199/ | ||
| Line 125: | Line 121: | ||
== Solution == | == Solution == | ||
* Get rid of reset / reinit entirely, and simply re-run the normal init sequence after tearing down almost everything. (What remains, is to be decided by testing - probably scenery, maybe nothing else at all). | * Get rid of reset / reinit entirely, and simply re-run the normal init sequence after tearing down almost everything. (What remains, is to be decided by testing - probably scenery, maybe nothing else at all). | ||
* The requires reliable deleting + cleanup of subsystems - i.e fixing and fixing all the places using statics incorrectly. Some work towards this has already been done. | * The requires reliable deleting + cleanup of subsystems - i.e fixing and fixing all the places using statics incorrectly. Some work towards this has already been done. | ||
| Line 133: | Line 128: | ||
== Benefits == | == Benefits == | ||
* No more 'X breaks on reset' bugs - less code to maintain and fewer special cases in the code. | * No more 'X breaks on reset' bugs - less code to maintain and fewer special cases in the code. | ||
* Dynamic switching of aircraft (saving/loading flights | * Dynamic switching of aircraft (saving/loading flights, see {{ticket|1151}}) | ||
** Since the property tree will be rebuilt, we can safely read a different -set.xml file without the universe imploding. | ** Since the property tree will be rebuilt, we can safely read a different -set.xml file without the universe imploding. | ||
* Restarting of Nasal (re-read scripts on the fly, also see [[Nasal Events]] [http://forum.flightgear.org/viewtopic.php?f=30&t=19487] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36668.html]) | * Restarting of Nasal (re-read scripts on the fly, also see [[Nasal Events]] [http://forum.flightgear.org/viewtopic.php?f=30&t=19487] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36668.html]) | ||
| Line 145: | Line 139: | ||
== Implementation == | == Implementation == | ||
* This is a complex change, which cannot easily be done incrementally. It will inevitably cause some breakage and issues while everything is tested. | * This is a complex change, which cannot easily be done incrementally. It will inevitably cause some breakage and issues while everything is tested. | ||
* The init / shutdown code, including FGGlobals, needs to be adjusted to do the actual deletion and run init again. Most of the other init steps (configuration options) are already re-factored in this direction anyway. | * The init / shutdown code, including FGGlobals, needs to be adjusted to do the actual deletion and run init again. Most of the other init steps (configuration options) are already re-factored in this direction anyway. | ||
| Line 156: | Line 149: | ||
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!): | 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 | * 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 {{flightgear commit|0f14a2d7}} | ||
* 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 | ||
| Line 175: | Line 168: | ||
** 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 | * 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 {{flightgear commit|a52c0882}}. 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]). | ||
* we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things Tom's Canvas code is already using the notion of a PropertyBasedElement which wraps SGSubsystemGroup and SGPropertyChangeListener. This means we could allocate/free groups of subsystems and treat them as run-levels e.g.: | * we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things Tom's Canvas code is already using the notion of a PropertyBasedElement which wraps SGSubsystemGroup and SGPropertyChangeListener. This means we could allocate/free groups of subsystems and treat them as run-levels e.g.: | ||
** CORE: logger, prop-interpolator, performance-mon | ** CORE: logger, prop-interpolator, performance-mon | ||
| Line 186: | Line 179: | ||
* as per [[Initializing Nasal early]], it would make sense to prepare delegating options.cxx and especially "presets" to scripting space | * as per [[Initializing Nasal early]], it would make sense to prepare delegating options.cxx and especially "presets" to scripting space | ||
* memory cleanup must be improved, see {{Issue|1559}}. | * memory cleanup must be improved, see {{Issue|1559}}. | ||
[[Category:Developer Plans]] | [[Category:Developer Plans]] | ||