New comment by tornaria on void-packages repository

https://github.com/void-linux/void-packages/pull/35730#issuecomment-1053637263

Comment:
I agree that we should wait for comments for upstream, although meanwhile sagemath is broken in a very annoying way.

About your comment on the optional use of `cysignals` here's my take:
 - pure python offers a way to install signal handlers via `signal.signal()`, and so for a pure python program that installs a custom sigint handler, saving and restoring python-level signals is necessary and good enough (no need to use `sigaction`). For example:
```python
$ ipython
Python 3.10.2 (main, Jan 15 2022, 03:11:32) [GCC 10.2.1 20201203]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: def h(x,y): print("Our custom handler received a sigint", x, y); raise KeyboardInterrupt

In [2]: import signal

In [3]: signal.signal(signal.SIGINT, h)
Out[3]: <cyfunction python_check_interrupt at 0x7f12316bcba0>

In [4]: while True: pass
^COur custom handler received a sigint 2 <frame at 0x55c760ab21c0, file '<ipython-input-4-b16dc615ea65>', line 1, code <module>>
---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
Input In [4], in <module>
----> 1 while True: pass

Input In [1], in h(x, y)
----> 1 def h(x,y): print("Our custom handler received a sigint", x, y); raise KeyboardInterrupt

KeyboardInterrupt: 

In [5]: 
```
The above snippet is broken with the version of `prompt_toolkit` that we ship in void, but it works with my patch (even without `cysignals`).
 - when a python program uses `sigaction` to install a custom signal handler, then yes, saving and restoring with `sigaction` is the only way to fix this issue. Unfortunately python doesn't offer any standard way to do that. The only package I know uses `sigaction` to change the sigint handler is `cysignals`. But if `cysignals` is being used to change the sigint handler, then for sure `cysignals` is available to save and restore so we are good!

> Furthermore, if managing signals set with `sigaction` is the right thing to do, it shouldn't be done only if the user chooses to install `cysignals`.


> Thus, either `cysignals` should become a hard requirement of `prompt_toolkit` or it should have its own method to save and restore these signals.

I don't think either is necessary and presumably `cysignals` supports less architectures than `prompt_toolkit` (indeed `sigaction` only makes sense on posix); having its own method requires C code, that would be very simple to copy from `cysignals.pysignals` except `prompt_toolkit` doesn't compile any C code so why make building it more complicated for no good reason).

In case another program or python package installs a custom sigint handler and suffers of this issue, we can figure out how to fix it (for instance, we make *that* package depend on python3-cysignals). Right now there aren't many packages in void that use prompt_toolkit. In any case, if they break because of this they are already broken, my fix won't make them more broken but possibly less broken.

> We really need some guidance from upstream about whether they intend to care about this problem at all and, if so, how they intend to solve it.

Sure.
 
> I don't want to maintain indefinitely a custom `prompt_toolkit` patch that pulls in `cysignals` to manage these signals. If upstream wants to depend on it, so be it. If they don't care about this problem at all, we'll need another solution.

I can help to maintain the patch, at least for the time being while the issue is (hopefully) resolved upstream, and I can help to figure out another solution if this one doesn't work in the end.