Right. I can see how that could be useful in some situations but presumably it wouldn't work very well for a very dynamic situation like a rocket in flight (changing height, orientation, fuel, thrust every millisecond)

And you still need a control loop to look for sensor changes? Its just a way of caching most of the computation?

It can work well for dynamic event-driven problems, with no need for a central busy loop[1]. Any sensor changes are responsible for triggering an update in any nodes that depend on it, who are responsible for triggering nodes that depend on those, and so on. One way to do it: abstract class Node, which has a list of child nodes that it loops through and alerts whenever there's been a state change in the parent node.

[1] There is a busy loop but it's only there to trigger tasks on a timer.

I’ve never seen this implemented well in a real-time setup. I’ve come to associate it with everything falling apart and otherwise being taped together in weird ways to function.

It sounds elegant, but I’m not convinced there’s a benefit to a model of abstractions of abstractions like this unless it’s done at the language level. In practice, I’ve only seen this produce a web of race conditions, performance issues, and system complexity. My experience is anecdotal.

> I’m not convinced there’s a benefit

I've seen it work well once, but others struggled to contribute to it because it was so complicated and it added little benefit to the usual busy loop approach. So I'm in the same boat as you.

One reason why this is dangerous is that you can see extremely large changes in the CPU load. For a bunch of cycles, there's apparently nothing to do, then there's a whole bunch of stuff to do, then there's almost nothing etc.

This makes it hard to reason about the overall capacity of the system (in terms of numbers of sensors and actuators). You will always end up uncertain whether you've ever really evaluated the "full load" condition, even if you formally test it in ways that say you have.