In zbus 1.x times, the signal methods in interface used to take &self and didn't require the strange SignalContext etc. That API however, made use of thread locals. When we reworked the API in 2.x to be completely async, it was no longer possible to use thread locals anymore since our futures could potentially be moved between threads of an async runtime w/o us knowing.
However, I think we can make the same/similar API work again w/o using any thread locals. The rough (I haven't yet thought it through) is:
interface macro generates a trait, let's call it MyIfaceSignals, where MyIface is the type Interface is being implemented for. This trait will contain all the signal methods from MyIface but with &self rather than the SignalContext arg.
The trait is implemented for zbus::object_server::InterfaceRef<MyIface> with all methods emitting the signal directly (since InterfaceRef has SignalContext in it.
zeenix
commented
1 week ago
In zbus 1.x times, the signal methods in
interfaceused to take&selfand didn't require the strangeSignalContextetc. That API however, made use of thread locals. When we reworked the API in 2.x to be completely async, it was no longer possible to use thread locals anymore since our futures could potentially be moved between threads of an async runtime w/o us knowing.However, I think we can make the same/similar API work again w/o using any thread locals. The rough (I haven't yet thought it through) is:
interfacemacro generates a trait, let's call itMyIfaceSignals, whereMyIfaceis the typeInterfaceis being implemented for. This trait will contain all the signal methods fromMyIfacebut with&selfrather than theSignalContextarg.zbus::object_server::InterfaceRef<MyIface>with all methods emitting the signal directly (sinceInterfaceRefhasSignalContextin it.This simple code demonstrates the idea: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8263c4aff9df3bdb2e432affc0957bb8
pros:
cons: