If I look correctly, metrics are currently only collected in System::run_actor_select_loop() -> recv(addr.message_rx) -> msg => arm. That opens a possibility to collect the metrics solely inside Actor::handle(), without any explicit involvement of System. For code reuse, this can be implemented through some MeteredActor wrapper around actual Actor. To achieve the same ergonomics as the current state, a MeteredSystem (containing System) could be introduced that would wrap each passed actor during spawn() (arriving de-facto near the starting point).
Potential advantages:
The "core API" would be free of this "specific" concern - who doesn't care about metrics wouldn't have to know about them. "Only pay for what you use".
The difference between System and SystemHandle would cease to exist, and these two could be merged into a single type. This difference was a source of light confusion when I initially read the API docs and code.
Metrics collection could be enabled only for some actors, not "all or none". (this is currently achievable by spawning multiple systems, with some slight resulting inconvenience).
Would allow more elaborate metrics collection patterns, like recording them every 10 messages, etc.
Disadvantages:
Too many wrappers could make things like reasoning, debugging, rustc errors more complicated. (I would expect that rustc is able to compile-out the abstractions for zero runtime overhead though).
If I look correctly, metrics are currently only collected in System::run_actor_select_loop() ->
recv(addr.message_rx) -> msg =>arm. That opens a possibility to collect the metrics solely inside Actor::handle(), without any explicit involvement ofSystem. For code reuse, this can be implemented through someMeteredActorwrapper around actual Actor. To achieve the same ergonomics as the current state, aMeteredSystem(containingSystem) could be introduced that would wrap each passed actor duringspawn()(arriving de-facto near the starting point).Potential advantages:
SystemandSystemHandlewould cease to exist, and these two could be merged into a single type. This difference was a source of light confusion when I initially read the API docs and code.Disadvantages:
This is spiritually similar to https://github.com/tonarino/actor/issues/26 - I have somehow fallen for Actor wrappers. ;-)