pbio/sys: Refactor status events to be handled synchronously #299
Conversation
This refactors a few names without changing any code, setting the stage for the next commit where we update the sys background process. We never quite adopted events across pbio, but only had a status set/clear handler in pbsys, with only one top level handler at pbsys_hmi_handle_status_change. Later, we can call it directly without casting the event data value to void * and back.
This was using broadcast, but there was ultimately only one receiver for this data. We can simplify this and avoid the risk of overrunning the event queue by calling it synchronously, which is safe for this event. After the refactoring in the previous commit, this is now a trivial change.
|
I think this will be OK, but it likely needs more work. I'm pretty sure that we have some processes that are depending on these broadcast events to "wake up" the process when the status changes even if they aren't explicitly checking the event. The main one that comes to mind is Bluetooth/USB, e.g. when the user program stops or when we get a hub shutdown request. Basically, we need to audit everywhere |
|
Thanks for the review!
This is one of those cases where #298 should really simplify things. Where this code used to broadcast, it can call We can wait with this one until #298 is merged. |
We never quite adopted events extensively across
pbio. We only have a status set/clear handler in pbsys, with only one top level event listener atpbsys_hmi_handle_status_change. We can call it directly without casting the event data value to void * onto an event queue, and then back again. Given the limited case we had, this was harder to follow than we ultimately needed, and risked overflowing the event queue as stated in an oldREVISITthat we can now address.Doing this simplifies the introduction of #298 by ensuring we don't need any event queue at all.