It IS, however, the set of all signals that trigger
an exit on either Linux or BSD systems. Linux is a
superset of the signal names supported on BSD, and
the unknown signals just fail to register, so we can
catch that easily enough.
Windows signals are a different set, since there are
signals that terminate Windows processes, but don't
terminate (or don't even exist) on Posix systems.
Don't bother with SIGKILL. It's uncatchable, which
means that we can't fire any callbacks anyway.
If a user does happen to register a handler on a non-
fatal signal like SIGWINCH or something, and then
exit, it'll end up firing process.emit('exit'), so
the handler will be fired anyway.
SIGBUS, SIGFPE, SIGSEGV and SIGILL, when not raised
artificially, inherently leave the process in a
state from which it is not safe to try and enter JS
listeners.
This is not the set of all possible signals.
It IS, however, the set of all signals that trigger an exit on either Linux or BSD systems. Linux is a superset of the signal names supported on BSD, and the unknown signals just fail to register, so we can catch that easily enough.
Windows signals are a different set, since there are signals that terminate Windows processes, but don't terminate (or don't even exist) on Posix systems.
Don't bother with SIGKILL. It's uncatchable, which means that we can't fire any callbacks anyway.
If a user does happen to register a handler on a non- fatal signal like SIGWINCH or something, and then exit, it'll end up firing
process.emit('exit'), so the handler will be fired anyway.SIGBUS, SIGFPE, SIGSEGV and SIGILL, when not raised artificially, inherently leave the process in a state from which it is not safe to try and enter JS listeners.