xiaoxiang781216 commented on PR #17352:
URL: https://github.com/apache/nuttx/pull/17352#issuecomment-3569035149
> > > When signals are disabled, the related POSIX APIs—including sleep,
usleep, kill, pkill, and pthread—will be disabled as well.
> >
> >
> > It's too limit that sleep/usleep can't be called when
CONFIG_DISABLE_SIGNALS equals true, so I would suggest that this feature should
be done by level:
> >
> > 1. disable all signal related functionality like this pr
> > 2. disable signal function related to signal handler(callback), but
keep other simple but frequnctly used function(e.g. wait/sigwait/ppoll).
> > 3. enable all signal functionality like before
>
> Upon reconsideration, I prefer to only allow disabling all signal-related
functionality, and re-implement the signal-dependent functions such as
sleep()/usleep() using the newly added scheduler-based sleep APIs.
>
not only sleep/usleep, my real concern is the following functions:
```
pid_t wait(FAR int *stat_loc);
int waitid(idtype_t idtype, id_t id, FAR siginfo_t *info, int options);
pid_t waitpid(pid_t pid, FAR int *stat_loc, int options);
```
These functions is important to make nsh work correctly.
> 1. This approach is clearer and safer. If we allow disabling only part of
the signal subsystem, we would need to modify the implementations of the
remaining signal functions.
But we just need skip the signal dispatch, no other change.
>At the same time, we cannot guarantee that those functions will continue to
behave exactly as before. Even worse, it becomes harder for users to understand
the actual impact of partially disabling signal features.
The rule is simple, signal action doesn't work, but all other signal related
feature work as before.
--
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]
