wangchdo commented on PR #17352:
URL: https://github.com/apache/nuttx/pull/17352#issuecomment-3561162145
> Thanks @wangchdo I did take a look at the changes, my questions below :-)
>
> > When signals are disabled, the related POSIX APIs—including sleep,
usleep, kill, pkill, and pthread—will be disabled as well.
>
> * Are you sure these are the only impacted places? Drivers / irq / read /
write / etc is not impacted?
This PR introduces an option for users to disable the signal subsystem. The
effects of disabling signals can be summarized in two major aspects:
**1. Source Files That Will Not Be Compiled**
When CONFIG_DISABLE_SIGNALS=y, the following files will be excluded from the
build:
```
libs/libc/signal/*.c
libs/libc/unistd/lib_sleep.c, libs/libc/unistd/lib_usleep.c
sched/signal/*.c
sched/group/group_signal.c
```
**2. Behavioral Changes in Code That Remains Compilable**
The following functional paths will be modified or bypassed when signals are
disabled:
1. posix_spawnattr_init() no longer initializes an empty signal mask
```
/* Empty signal mask */
#ifndef CONFIG_DISABLE_SIGNALS
sigemptyset(&attr->sigmask);
#endif
2. group_release() will not release pending signals
```
/* Release pending signals */
#ifndef CONFIG_DISABLE_SIGNALS
nxsig_release(group);
#endif
```
3. nx_start() will not initialize the signal facility
```
/* Initialize the signal facility (if in link) */
#ifndef CONFIG_DISABLE_SIGNALS
nxsig_initialize();
#endif
```
4. nx_pthread_exit() will skip signal-related cleanup
```
#ifndef CONFIG_DISABLE_SIGNALS
sigfillset(&set);
nxsig_procmask(SIG_SETMASK, &set, NULL);
#endif
```
5. nxtask_exithook() will not clean up signal queues
```
#ifndef CONFIG_DISABLE_SIGNALS
nxsig_cleanup(tcb); /* Deallocate Signal lists */
#endif
```
6. nxtask_reset_task() will not reset signal queues and masks
```
#ifndef CONFIG_DISABLE_SIGNALS
nxsig_cleanup(tcb); /* Deallocate Signal lists */
sigemptyset(&tcb->sigprocmask); /* Reset sigprocmask */
#endif
```
7. nxthread_setup_scheduler() will no longer inherit the parent’s signal mask
```
#ifndef CONFIG_DISABLE_SIGNALS
/* exec(), pthread_create(), task_create(), and vfork() all
* inherit the signal mask of the parent thread.
*/
tcb->sigprocmask = this_task()->sigprocmask;
#endif
```
8. spawn_execattrs() will not apply signal-mask attributes
```
#ifndef CONFIG_DISABLE_SIGNALS
if ((attr->flags & POSIX_SPAWN_SETSIGMASK) != 0)
{
FAR struct tcb_s *tcb = nxsched_get_tcb(pid);
if (tcb)
{
tcb->sigprocmask = attr->sigmask;
}
}
#endif
```
9. timer_signotify() will not send signal notifications
```
#ifndef CONFIG_DISABLE_SIGNALS
# ifdef CONFIG_SIG_EVTHREAD
DEBUGVERIFY(nxsig_notification(timer->pt_owner, &timer->pt_event,
SI_TIMER, &timer->pt_work));
# else
DEBUGVERIFY(nxsig_notification(timer->pt_owner, &timer->pt_event,
SI_TIMER, NULL));
# endif
#endif
```
**Impact Analysis**
Driver, IRQ, read/write, and similar subsystems are not affected:
- Their implementations are unchanged.
- If they relied on code that is no longer compiled, the link stage would
fail — which does not occur.
- If they depend on code paths that are conditionally updated, the behavior
remains correct, because these updates mainly affect thread/task
initialization, setup, and exit paths, and do not influence driver or IRQ
execution.
**Additional Background**
For reference:
- PR #17200 introduces scheduled-sleep support.
- PR #17204 replaces all signal-based sleep implementations in drivers and
the filesystem with scheduled sleep.
These changes significantly reduce the dependency on signals across the
system, making the signal-disable option more feasible and less intrusive.
> * Are you sure that this change will not leave user in almost bare-metal
state?
Please review my conclusion about the detailed effects of this change above.
I am confident your concern will not occur.
> * For now I can see that in Kconfig signals can be disabled. I cannot see
dependency in sleep/usleep/kill/pkill/pthread/etc on signals in Kconfig.
Yes this Kconfig relations should be imroved
> * So the program will crash when for instance usleep is called but signals
are disabled, or wont build, right?
If a program calls sleep or usleep, the build will fail when signals are
disabled. If the program truly requires sleep functionality, there are two
options:
**Option 1**
Signals have two major purposes:
Invoking the signal handler in the target process/task
Waking up a target thread (similar to a semaphore post)
I can introduce a finer-grained configuration option so that only signal
handler functionality is disabled while preserving the wake-up mechanism. This
would allow sleep and usleep to remain available.
**Option 2**
Since PR #17200 introduces scheduled-sleep support and PR #17204 replaces
all signal-based sleep implementations in drivers and the filesystem with
scheduled sleep, users can switch to the scheduled-sleep APIs as an alternative
for sleep/usleep.
> * We need to sort the dependencies out before merge and/or we need to
clearly know what other functionalities are impacted.
Yes I agree
> * Disabling signals in Kconfig should also disable impacted
functionalities automatically I see that as most user friendly and safe
approach.
Yes I agree
>
> > ostest is heavily dependent on POSIX APIs—including sleep, usleep, kill,
pkill, and pthread. Therefore, to disable signal support, ostest must also be
disabled until it is refactored to reduce its reliance on these APIs.
>
> * How much work is needed to update ostest to work without signals and
other impacted functionalitites?
> * This is our main tool of runtime confirmation that all works as expected.
> * Having working ostest without signals would reveal potential problems in
other areas than need an update.
> * Would it be possible to update ostest before this PR is merged?
>
Of course, I can do this
> > Disabling the signal mechanism significantly reduces system footprint
and complexity. It can also improve real-time performance during thread
creation and context switching.
>
> * Would it be possible to provide measured Flash/Ram usage with and
without signals disabled?
> * Would it be possible to measure runtime code improvement?
>
I will give details soon
> This functionality deserves a mention in the documentation :-)
>
> * https://nuttx.apache.org/docs/latest/reference/user/07_signals.html
> *
https://nuttx.apache.org/docs/latest/guides/signaling_sem_priority_inheritance.html
> *
https://nuttx.apache.org/docs/latest/standards/posix.html#posix-realtime-signals
> * ...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
