New submission from Enji Cooper <yaneurab...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue39565> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
