We need to clarify the ownership and lifecycle semantics of Configuration.Close() and node-level closing. Right now it is not obvious whether closing a configuration should always close the underlying nodes, whether nodes can be shared across configurations safely, or whether some form of reference counting is needed to avoid premature shutdown.
The task should map the current close path through config.go, mgr.go, node.go, and the underlying channel cleanup so the intended ownership model is explicit. From there, define the desired behavior for shared nodes, reused configurations, and repeated close calls.
Reference counting is one possible implementation strategy, but it should not be assumed up front. If a simpler ownership rule can make the behavior predictable, prefer that over a more complex lifecycle mechanism. The deliverable is a concrete design and, if the design is clear enough, a bounded implementation plan.
We need to clarify the ownership and lifecycle semantics of
Configuration.Close()and node-level closing. Right now it is not obvious whether closing a configuration should always close the underlying nodes, whether nodes can be shared across configurations safely, or whether some form of reference counting is needed to avoid premature shutdown.The task should map the current close path through
config.go,mgr.go,node.go, and the underlying channel cleanup so the intended ownership model is explicit. From there, define the desired behavior for shared nodes, reused configurations, and repeated close calls.Reference counting is one possible implementation strategy, but it should not be assumed up front. If a simpler ownership rule can make the behavior predictable, prefer that over a more complex lifecycle mechanism. The deliverable is a concrete design and, if the design is clear enough, a bounded implementation plan.