[Feature Request] Implement Pre-Termination event for graceful sysmodule shutdown

[o0Zz]

Hi,

I'm currently working on a module called sys-con and would like to enable/disable it using OVL-Sysmodule. However, I’ve noticed that OVL-Sysmodule does not properly close the sysmodule (pmshellTerminateProgram) and doesn’t provide a way for the sysmodule to shut down gracefully. (If I’ve missed something, please feel free to correct me).

This behavior is problematic because the sys-con module relies on hiddbgAttachHdlsWorkBuffer, which must be properly deinitialized to prevent issues. Without a graceful shutdown mechanism, this will cause the console to crash, as described in this GitHub issue: sys-con issue #52.

Do you think it would be possible to implement an event or signal, such as a 1-second notification before terminating the sysmodule, to let a chance to the sysmodule to close gracefully? (Example: In the toolbox.json a kind of gracefully_shutdown_delay: 1 where 1 means 1s to terminate before killing it)

Thank you

[WerWolv]

There's not really any way in Horizon to send signals to other applications. The only way to do that is by using the IPC system which would require all sysmodules to implement an IPC server which then in turn would prevent these sysmodules from starting again properly because because they can't register their IPC server again.

Starting and Stopping sysmodules is not really something HOS was ever designed to be doing so there's really not much that can be done about this issue. You're far from the only one that has problems with this but it really is what it is.

[o0Zz]

Got it, thanks for the reply! I understand now. What about using the cheat method for sysmodules? Cheats work by writing directly to memory to change its state. Could we apply a similar trick with a sysmodule?

For instance, we could determine the sysmodule's memory address and simulate a signal by writing to a specific part of its memory. The sysmodule would just need to reserve a portion of its memory (possibly defined by including the relative address in toolbox.json) and poll this memory region for changes.

Would this approach be viable from your point of view ?