[Flightgear-devel] Designs for the subsystem manager/factory.

[Edward d'A. <tru...@gm...>]

>> For the dynamic dependency resolution, I haven't looked at which
algorithms
>> would be best for subsystems.  But if I can implement this at the same
time
>> as implementing the subsystem independence +testing, I don't think a
>> specialised algorithm would be needed to make sure the order is perfectly
>> correct.  Basic topological sorting might do [1].
>
>
> I don’t think an especially complex algorithm is needed - the dependencies
> are a DAG, and not especially deep. The only thing i can imagine we
*might*
> need, is to fully expand the dependency tree on creation of a subsystem,
to
> find the ‘most leaf’ dependency, and ensure we init that first. But again
> this is not especially hard to setup.

Great.  I was thinking of trying the "depth-first search" first as that
looks like fun, so it might just work.  For the test suite I was
envisioning dynamically resolving the dependencies to rebuild the subsystem
order as they are added or removed.  I guess that would be about the same.


> One thing to be aware of, we do rely on the subsystem-groups to control
> order of processing with the update() call - and this is important for
> reducing latency in some situations (eg, FDM is processed before Nasal). I
> don’t think there’s any problem here, but in the past when I changed the
> (hard-coded) subsystem creation code, I did get some odd bugs due to a
> subsystem running before another, when previously it had run after.

I hadn't though of that, but if a new type of "update dependency" was also
added, then it wouldn't be a problem.  The subsystem manager could then
build the dependency tree by asking for all required, optional, and update
dependencies.  I think that would solve this issue.


> I think I fixed all the cases of that at the time, but there’s probably a
> few more lurking.

I guess some of these might be very subtle.


> How do you want to proceed with managing these new APIs? I’d prefer to do
> them separately to your testing changes if you don’t mind, and ideally on
> next so that I can contribute as well. Or we can make a topic branch and
> both work there?

I was thinking of writing an initial example on a testing branch just as a
first experiment. But we could do this on next.  I can see that my test
suite work will be a strong driving factor as, for example, I need this to
debug the moon position property bug. In any case, I will need to push to
my forks so that basic c++ mistakes can be caught.

I think we should develop this in combination with basic tests to avoid
problems in unrelated tests.  For the subsystem supplied dependencies, I
was thinking of the following SGSubsystem base class public virtual
functions:

dependenciesRequired()
dependenciesOptional()
dependenciesUpdate()
dependenciesNonSubsystem()

The last would be useful in the test suite with subsystem manager flags
tracking the initialization status of non-subsystem components, e.g.
FGRenderer and SGSky.  Parsing this for all subsystems might make an
interesting subsystem conversion todo list ;)  The functions could return
empty std::vector<std::string> objects for leaf nodes and non-implemented
subsystems.

For the rest, I think I need to experiment a little.  A nice initial
isolated subsystem set would be useful to find.

Regards,

Edward