[issue39565] Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc

[Enji Cooper]

New submission from Enji Cooper <yaneurabeya at gmail.com>:

The code in Modules/signalmodule.c makes a number of assumptions of what signals are considered valid, as well as what handlers need to be setup as part of the core interpreter.

For example: much of the initialization of signal handlers, etc, is actually keyed off of NSIG, as defined (and guessed on) here: https://github.com/python/cpython/blob/master/Modules/signalmodule.c#L50 . The problem with this is that it makes it impossible for end-users to use `signal.signal`, et al with signal numbers outside of `NSIG`, which includes realtime signals.

Furthermore, if one is to extend the size of `NSIG`, it results in an increased O(n) iteration over all of the signals if/when a handler needs to be handled (set or cleared).

Proposal:
The best way to handle this, in my opinion, is to use a dict-like container to iterate over all of the handlers and rely on the OS to trickle up errors in the signal(3) libcall, as opposed to thinking that the definitions/assumptions in signalmodule.c are absolutely correct.

This may or may not be possible, however, depending on code needing to be reentrant, but it would be nice to leverage a middle ground solution of some kind *shrug*.

----------
components: Interpreter Core
messages: 361458
nosy: ngie
priority: normal
severity: normal
status: open
title: Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39565>
_______________________________________