Skip to content

Unsubscribe callback handlers when updating a module #173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
carllocos opened this issue May 10, 2023 · 4 comments
Open

Unsubscribe callback handlers when updating a module #173

carllocos opened this issue May 10, 2023 · 4 comments

Comments

@carllocos
Copy link
Contributor

When updating a module, we should unsubscribe the callback handlers and this also means that for a MCU we should unsubscribe the service routine.

However, I believe that this may not even be necessary. The reason is that normally when we would update a module. The module should be persisted on the MCU so to survive potential reboots (I already opened an issue for this #121). If we persist a module and we decide to reboot the device, then the ISR get automatically unsubscribed. Meaning that this issue becomes irrelevant. However, I believe as long as we do not have the persisting feature yet, we should manually unsubscribe the ISRs.

What do you think @tolauwae?

@carllocos carllocos changed the title Unsubscribe from interrupts when updating a module Unsubscribe callback handlers when updating a module May 10, 2023
@tolauwae
Copy link
Member

I agree. The callback system should definitely be reset completely when a new module gets loaded. Except for the event queue imo.

For the persistant module. When that feature is implemented, I still wouldn't reboot the device on a module update because that is pretty slow. So I would still reset the callback system manually on module update.

@carllocos
Copy link
Contributor Author

Actually, the decision of rebooting or not is dependent on the use case and should come from the developers. As of that, both options should be possible.

@tolauwae tolauwae linked a pull request Jul 13, 2023 that will close this issue
@tolauwae tolauwae removed bug labels Jan 19, 2025
@tolauwae
Copy link
Member

Actually, the decision of rebooting or not is dependent on the use case and should come from the developers. As of that, both options should be possible.

@carllocos With the new issue system I'm going through the old issue backlog. For the reboot after module update, there are already a two debug operations that can help with this: halt and reset. imo this give developers enough control over this decision.

I added the callback reset as a subissue (bug fix) and might have time to work on it soon.

@carllocos
Copy link
Contributor Author

cool! I was not aware of halt and reset.

For now, unsubscribing the callbacks (without reboot) is not a priority and if needed could easily be solved imo.

Thanks for keeping it as a subissue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants