cederom commented on PR #17352: URL: https://github.com/apache/nuttx/pull/17352#issuecomment-3568783104
> > > 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. > > 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. 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. > > 2. With PR [sched/sleep: add support for scheduling sleep #17200](https://github.com/apache/nuttx/pull/17200) introducing scheduler-based sleep support, and PR [sched/sleep: replace all Signal-based sleep implement to Scheduled sleep #17204](https://github.com/apache/nuttx/pull/17204) replacing all signal-based sleep implementations in drivers and the filesystem with scheduler-based versions, the overall dependency on signals has already been significantly reduced. > > 3. We can re-implement the libc sleep()/usleep() functions using the new API added by PR [sched/sleep: Add nxched_nanosleep() API #17368](https://github.com/apache/nuttx/pull/17368). This will even be more lightweight compared to the current signal-based wait mechanism. Thank you @wangchdo :-) * I also think that when Signals are not here that means signals are not here (not just part of the signals). * Would it be possible that you implement sleep alternatives that would not depend on signals? That way we could compare full implementation on a working prototype, make some testing and measurements. Then decide if we move forward with that approach. * Would alternative sleep implementation also work when signals are enabled? Or two implementations would have to co-exist one with for signals and the other without signals? * What are risks and benefits here? * backward compatibility? * portability? * timing precision? * code size? * others? -- 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]
