Hi Charles,
My use case is a dynamic system with centralized resource management and control. I'd like to be able to instantiate specific-purpose subsystems isolated from each other and from the resource manager. When a subsystem is created, its launcher has to bargain with the manager (through the loader and a modified loader session) to obtain resources. It's a sort of fusion between the cli_monitor and the loader. The subsystems should however be able to yield back resources when, for example, one of their children exits.
thank you for providing more details. I am actually thinking in a very similar direction: Like you, I want to manage subsystems dynamically but don't want to implement the (potentially complex) management component as the parent of the managed subsystems. My current idea is to enhance init so that it will be able to respond to configuration changes in a sensible way.
Right now, init replaces all children with new instances each time when its configuration changes. In the future, I plan to let init apply only the actual configuration changes. E.g., killing the subsystems that disappeared in the new config, starting new subsystems for new appearing <start> nodes, adjusting the resource assignments, or propagating changes in the subsystem's respective <config> nodes. Furthermore, init would produce reports about the state of the running subsystems, the RAM usage, etc.
BTW, as far as I know, Johannes Schlatow already implemented a prototype of this approach.
With the new (dynamic) version of init in place, CLI monitor would not manage subsystems as its children any longer. It would merely generate configurations for an instance of init that can live somewhere else in the component tree. Alternatively to using CLI monitor, system scenarios could be interactively modified on-the-fly by editing the config of a dynamic init via Vim running inside Noux. Wouldn't that be cool? :-)
I wonder, would this principle design satisfy your use case, too?
As a side question, how is the quota associated with a session registered? Is every component involved in the session creation responsible for remembering the quota it transfered?
Yes. The common parent of the client and server keeps those records. This is natural because the common parent actually owns both client and server and deliberately moves resource budgets between them. The resource trading solely happens along the branches of the component tree.
Cheers Norman