Basically, signal has two reaction: 1. Call the signal handler function in the target process/task 2. Wake up the target thread just like sem post
The major memory/code size contribution comes from the first item, the second item consumes the small code/memory, but could keep many frequently used functions(e.g. sleep/usleep/wait etc.). So, I would suggest that the signal is disabled by level to make it more useful in different cases: 1. Disable all signal related functionality( https://github.com/apache/nuttx/pull/17352) 2. Disable signal handler(callback), but keep signal wakeup functionality (https://github.com/apache/nuttx/pull/17357) 3. Enable all signal functionality like before On Fri, Nov 21, 2025 at 9:33 AM Tomek CEDRO <[email protected]> wrote: > After another look my concerns: > > What is the real impact of disabling signals? Only sleep, usleep, > kill, pkill, and pthread? How about irq / drivers / read / write / > etc? > > We need to know exactly what functionalities are impacted even if this > is "use at your own risk" option. > > I think that ostest should be updated to work without signals before > PR can be merhed just to make sure and confirm what functionalities > are impacted. > > Some mention in the documentation would be nice to have? For instance > that it can be done, what will stop working, what memory and cpu > cycles amount is saved? > > I asked for measurements of comparison between flash / ram / cpu > cycles with signals enabled and disabled, just to have confirmation of > possible advantages. > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
