I've counted 28 signals specified in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html and 2 (SIGUSR1 and SIGUSR2) are already reserved for application needs. So 31 - (28 - 2) == 5. One signal value is "reserved" for SIGWORK, so it makes 4 signal values that can be used by application without any questions.
I came from a more "traditional" RTOS environment and despite that I started with Nucleus 2 that had implementation for signals (not POSIX of course), but nobody used it in that environment, so I need some more education here. When you are talking about "realtime signals", then what use case do you mean? Because per my understanding there is no way to do publish / subscribe with signals and signal number and process ID make a tuple, so same signal value can have a different meaning for process A and process B. The things seems to be more complicated in case of groups support. What is the number of "realtime signals" used in applications that are in the field? I would like to understand the issue deeper before rushing with the solution. We can adapt most of the modern MCUs to use uint64_t as segnal set holder (that of cause is depending on CONFIG_HAVE_LONG_LONG and some compilers will not have that), but that will leave less powerful variants with 32 bit signal set as a fallback. Maybe for those systems we do not need so many realtime signals, so that will be an "easy win". Anyway I need some more information to scope the work. Best regards, Petro вт, 21 бер. 2023 р. о 22:11 Gregory Nutt <spudan...@gmail.com> пише: > Linux supports 64 signals. Originally it supported 32 signals but: > > The addition of real-time signals required the widening of the signal > set structure (/sigset_t/) from 32 to 64 bits. Consequently, various > system calls were superseded by new system calls that supported the larger > signal sets. > https://man7.org/linux/man-pages/man7/signal.7.html > > We really have the same issue, shouldn't the MAX_SIGNO value be changed > to 63? if it is left at 32 and all of the standard signals are enabled, > then there is not many signals left for real time signals. > > On 3/21/2023 1:56 PM, Gregory Nutt wrote: > > I think I am mixing three related things here: > > > > 1. OPEN_MAX which controls the number of open files. That is 256 > > 2. FD_SETSIZE which is the size of the fd_set. That is the set passed > > to select() > > 3. Number of signals MAX_SIGNO which is really almost unrelated. It is > > only related through opening signals. > > > > I get myself confused at time so don't take this too seriously. I am > > probably inflating the issue. > > > > Greg > > > > On 3/21/2023 1:41 PM, Gregory Nutt wrote: > >> > >>> I think I missed the change that expanded signal values to 255 and I > >>> think > >>> that GOOD_SIGNO() macro still checks for <= 31. > >> > >> These 463a4377331, 24bd80eb84d, fa3e0faffcb, 10852dcc25c > >> > >> Yes, MAX_SIGNO and GOOD_SIGNO are wrong. I also created an Issue for > >> this: https://github.com/apache/nuttx/issues/8869 . I have not > >> carefully analyzed those, but it looks like there could be lots of > >> issues if the signal number is > 31. > >> > >>> I will re-examine the code and find it out. I would be glad to > >>> clean-up the > >>> signal values reconfiguration code however recently I saw e-mail thread > >>> that some custom boards code may rely on reconfigured values. Anyway > >>> that > >>> can be a "breaking change" that will make things easier (IMO). > >> > >> Well, if we want to proceed this way I think we only need to publish > >> the breaking change in this dev list as a proper notice of the change. > >> > >> Signal numbers are really arbitrary (other than when used with the > >> kill command) and it certainly can't make any technical difference > >> which numbers are used for which signals. > >> > >> It used to be that if a system used a lot of "realtime signals", > >> i.e., those with no pre-defined meaning, then you might need to > >> change some of the standard signals to pack them down to free up more > >> for use as pre-defined signals. But that should not longer be > >> necessary. > >> > >> > >> > >> > > >
