Ok, I think I've come to some final conclusions on run-levels and
subsystem dependencies. Here is what I propose:
- add a 'bool is_running()' check to SGSubsystem, and expose the
value via a place in the property tree. Suggestions for where that
should be on a postcard. I'll probably add a helper on the subsystem
manager to check the bool value by name, though it's equivalent to
doing 'fgReadBool()' on the property.
- define many more groups, which hence simplifies expressing the
dependencies for subsystems or Nasal scripts. Since groups are
subsystems, they get their own name in the property tree, and their
own 'is-running' value.
(the critical bit)
- Allow subsystems to declare a dependency on other subsystems
explicitly, and have the groups and manager track these values
internally. When initializing a subsystem, the manager will first
init each dependency (or possibly, not allow the init until the
dependencies are running). Similarly for reinit and resets, dependent
subsystems can automatically be reinited. In the long run, I expect
this to make re-init and features like switching aircraft become
possible: the 'aircraft chooser' would re-init the 'aircraft' group,
and and dependent subsystems (panel, cockpit?) would automatically be
re-inited as well.
In terms of the implementation, this amounts to storing an extra
'dependents' list on SGSubsystem, which I think is fine in terms of
complexity and maintainability; even as the dependency tree gets more
complex, it will always be possible to explore it fully starting from
the manager (eg, you could dump it out to stdout).
If subsystems wish to be tolerant of other subsystems not being
running (rather like a 'weak import' in a shared lib, they can check
the 'runningness' dynamically any time they wish (Jim's suggestion),
but in general I think most subsystems won't need to.
The final thing will be to define at least one and maybe several
dummy groups that exist purely to trigger Nasal scripts: notably one
for some of the current scripts that depends on 'nearly everything'.
Or we can just fix the current Nasal scripts to listen to the
is_running properties, which is a much neater solution (what Melchior
was suggesting yesterday)
In terms of coding this, I'll make the changes to SGSubsystem and the
manager, which shouldn't affect the current code at all (since there
won't be any dependencies expressed!), and then get the properties
defined. Then I'll work out an initial set of groups (I'll probably
get this wrong, but I'm sure people will tell me), and define the
dependencies. When that change is committed, the call to
'fgInitSubsystems' will effectively be replaced by a call to globals-
>subsystem_manager->start("everything_group");
The next step will be to change the initialization sequence to
actually start up some groups incrementally, which of course was my
original issue; I will start the systems I need (Nasal, GUI and
input) early. This might also help make the startup progress a bit
more fine-grained.
BTW, if anyone wants to make a few more things be subsystems
(<cough>FGTileMgr<cough>), they could then be integrated into this
scheme in a much more graceful fashion. Actually, it /looks/ as if
making the tile manager a subsystem is pretty straight-forward, but
perhaps other people know better.
As always, comments appreciated.
James
--
They are laughing with me, not at me.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
