Drop _NSIG to 42 instead of 65 (XCC)
authorKevin Klues <klueska@cs.berkeley.edu>
Fri, 5 Jun 2015 23:14:54 +0000 (16:14 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 12 Jun 2015 16:03:18 +0000 (12:03 -0400)
commit29d076658b927578d4d5c215ed4afa62efe2c02c
tree7220e8eef940fca7e324414c604956fa7a531f9c
parent5c588a74d6170fc045bbe40e88ee91d2b9618ce0
Drop _NSIG to 42 instead of 65 (XCC)

_NSIG represents the biggest signal number + 1 (including real-time signals).
We choose 42 in homage to h2g2, but also to show that it's not a magic number,
like 32 or 64.  It just happens to be the number of rt signals that we may
(probably won't support in the future).  At any rate, this number must ALWAYS
be <= 64 because we are using a long to represent a sigset.  In Akaros we will
likely impelment all necessary real-time stuff (if we need it) using events
directly, so this point is moot.  Leaving it at 65 was problematic though
because you can't represent all signals (based 1) in a single long, adding to
weird bugs that we would like to avoid in the future.

This helped to fix a bug whee I was previously trying to optimize my
signhandler array to only create (_NSIG - 1) entries because I knew
there were only 64 signals (0 is invalid), but I messed up my mappings
when reuqired to subtract 1 when indexing into this array
to get my signal.  Better to just create one extra entry and call it a
day. However, we need to make sure that all signals can be represented
in our sigmasks (Go cares about this for example, as it installs
handlers for all of its signals up to _NSIG).  If something is off here,
we are (and have been) screwed.
kern/include/ros/bits/posix_signum.h
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/bits/signum.h
user/parlib/signal.c