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.
