agronholm / anyio

High level asynchronous concurrency and networking framework that works on top of either trio or asyncio
MIT License
1.78k stars 135 forks source link

Restore signal handlers at the end of `open_signal_receiver`. #689

Open jonathanslenders opened 7 months ago

jonathanslenders commented 7 months ago

Things to check first

Feature description

Would it be possible to restore the original signal handlers at the end of open_signal_receiver instead of only removing them? I see that currently, we don't do that. Is there reason for this?

To restore signal handlers, they also have to be restored using ctypes after calling remove_signal_handler. See this code for an example on how to do that: https://github.com/prompt-toolkit/python-prompt-toolkit/blob/465ab02854763fafc0099a2e38a56328c1cb0625/src/prompt_toolkit/application/application.py#L1596

Use case

(Use case is obvious I think. We have an application for which a main signal handler is installed at the beginning, however, during a portion of the code, we want to use open_signal_receiver to override the signal handler for that portion.)

agronholm commented 7 months ago

This is impossible to do with asyncio's API.

jonathanslenders commented 7 months ago

Right, I see it's mentioned in the docs here: https://anyio.readthedocs.io/en/stable/api.html#anyio.open_signal_receiver

I'd think we could simply pop the current handler from get_running_loop()._signal_handlers. Why would that be a private API? Are you aware of any effort on the asyncio side to expose a public API for this?

agronholm commented 7 months ago

Why would that be a private API?

If it's named with a leading underscore, and not included in the documentation, then it's private API. That said, maybe signal handling on asyncio could be done using the signal module directly, while jumping through some hoops? That would be a cleaner solution.