Example situation: I want to monitor the state of a network connection (state "up" or state "down") and turn an LED on or off accordingly.
I could write a service that checks the connection (for example by pinging) and uses ubus to emit notifications or events when it goes up or down. The LED controller could then subscribe to those notifications or events, and toggle the LED when they happen. The remaining problem is that, when the LED controller starts, it does not know the state of the connection until the next state change.
If I try to solve it by first asking for the current state (something like ubus call connection state) and then subscribing to any changes (ubus subscribe connection or ubus listen connection), I risk missing a state change in between the two calls.
How do I ask for the current state, and subscribe to state changes, atomically?
The LEDs was just an example. I want to monitor the state of various things, distribute state changes over ubus (unless some other method is better), and react to those state changes.
Is atomicity really required?
I would suggest to reverse the order: subscribe first, then retrieve the current state.
Events shortly before state retrieval might be included, but I guess this is more easily handled than events missing?
Disclaimer: I have no experience working with ubus programmatically, please take this as general advice not related to a specific mechanism.
I don't really know yet, but I'm sure I (and others) will want to have something like this. Reacting to state changes is a fundamental thing.
Indeed. How can one achieve that in a shell script or in ucode without running into concurrency problems, where it becomes uncertain in which order things have really happened?