Discussion: per-interface SmRegistry for multi-agent-in-one-process

[Thecave3]

Summary

SmRegistry is currently a process-wide singleton (SmRegistry::instance()), so every E3Interface in a process shares one SM table. PR #29 proposed making it a per-E3Interface member. That's a structural change to a public header and ~10 call sites, unrelated to the setup-wedge bug (#28) it was bundled with, so we're splitting it out for its own discussion and review.

Motivation (to be confirmed)

A process-wide registry breaks any process hosting more than one E3 agent:

1. Registering an SM with the same ran_function_id on a second, independent agent fails with SM_ALREADY_REGISTERED.
2. E3Interface::stop() clears the shared registry, wiping the Service Models of every other RAN-role agent still running in the process.

The scenarios where this matters are multi-agent-in-one-process: integration tests, the latency benchmark, and colocated RAN+dApp deployments.

Open question: is multi-agent-in-one-process a configuration we want to officially support and commit to maintaining? The answer decides whether this refactor is worth its cost.

Proposed change (if we proceed)

• Each E3Interface owns an SmRegistry member; all e3_interface.cpp call sites route through the owning interface's registry; stop() clears only the agent's own SMs.
• SmRegistry loses instance() and gets a public constructor.

Notes / caveats

• Behavioral change: with clear() only invoked from stop(), destroying an E3Interface without calling stop() would destroy the SM objects via their C++ destructors but never call their destroy() lifecycle hook (the singleton previously lived for the whole process).
• ABI: SmRegistry is a public header symbol, but no external consumer references SmRegistry::instance() (OAI / spear-dApp are clean), so the API break is internal-only.
• A regression test (test_multi_agent_registry) accompanies the change and moves with it.

Context

Split out of PR #29 review.

[Ninjabippo1205]

I'd argue yes, multi-agent-in-one-process is worth supporting officially, mainly because we already rely on it ourselves:

• The integration tests and the full-loop latency benchmark run a RAN-role and a dApp-role agent in the same process today. The recent log-path change (Improve E3 logging: errno on failure + configurable, uid-namespaced log path #33) even calls this configuration out explicitly ("integration tests, the latency benchmark, or production multi-peer dApps") and was partly motivated by it.
• A dApp that talks to more than one E3 agent (multi-cell sensing, or a dApp bridging two RAN functions served by different agents) needs several E3Agent instances in one process. That works today only because dApp-role agents never touch the registry. Any process that hosts two RAN-role agents, for example one E3 termination per DU in a combined deployment or simply a test harness, hits the singleton immediately.
• The cost side is small: the refactor touches one internal class and ~10 call sites in e3_interface.cpp, has no wire/ABI impact, and no external consumer references SmRegistry::instance() (as noted above).

On the caveats:

• The lifecycle concern (destroying an interface without stop() skips the SMs' destroy() hook) is addressed in the branch I have ready: ~SmRegistry runs clear(), i.e. stop-if-running then destroy(), so the hooks fire on every teardown path, with a regression test for exactly that case. Worth noting the singleton never actually provided this guarantee either: it was simply never torn down, so destroy() silently never ran at process exit.
• Since SmRegistry::instance() disappears from an installed header, I'd bump VERSION accordingly in the PR.

The implementation (including test_multi_agent_registry) is complete on top of current main. Happy to open the PR whenever we agree this is a configuration we want to commit to.

[Thecave3]

multi-agent-in-one-process is worth supporting officially

I agree with the support, i disagree with the changes proposed.

• That works today only because dApp-role agents never touch the registry. Any process that hosts two RAN-role agents, for example one E3 termination per DU in a combined deployment or simply a test harness, hits the singleton immediately.

1. Why a dApp would want to access the SM Registry?

• , for example one E3 termination per DU in a combined deployment or simply a test harness, hits the singleton immediately.

2. Why you want two DUs in the same host? I can see a casa if libe3 is serving both a dApp and a RAN in the same context, but since dApp doesn't access the SM Registry it should be independent

The implementation (including test_multi_agent_registry) is complete on top of current main. Happy to open the PR whenever we agree this is a configuration we want to commit to.

I would like to first understand the case itself: I see a possible issue on the singleton when you have 2 instances of E3Agents that are both serving the RAN over the same process, but when is the case?