Exit terminal interface gracefully on signals#10185
Conversation
Closes ipythongh-9944 This sets signal handlers for SIGTERM and SIGHUP while the prompt_toolkit prompt is active, letting it clean up the terminal before the process exits. When the prompt is not active, we restore the previous signals. This can't work (as far as I know) if other code has set signal handlers at the C level. I don't think this is likely to come up often, but there's a new config option catch_signals=False which users can set to disable our manipulation of signal handlers.
They don't exist on Windows
|
It would be nice if this would also close IPython gracefully: With this branch, this code goes into an infinite loop. |
|
Instead of trying to save and restore signals (which is guaranteed to fail for C-level signal handlers), I would much prefer if the signal handler would be installed just once at startup. |
|
Apart from the manipulation of the signal handlers, this code works fine for me and I would be happy to support this in |
|
I restore the default signal handler so that the default behaviour applies while user code is running. I tried installing it at the start and leaving it in place, but then SIGTERM during user code only exits once it would display the next prompt. |
As you say yourself, this doesn't quite work when signal handlers have been installed at the C level.
I'd rather try to fix this instead... |
|
It's easy enough to stop Python code by raising an exception, but if the main thread is inside some long running C code, I don't know of a good way to stop it on a signal from Python. I think setting it back to the default is the best option here, even if that means that people using C signal handlers have to disable our signal handling functionality. I've brought this up on a Python issue here: http://bugs.python.org/issue13285 |
|
Added a change in the what's new. |
|
I suggest we move forward with this even if it's not perfect. We can refine in 5.3 if needed. |
Please no! This is going to break |
|
Or at least make |
|
Another alternative: make it easy to change |
|
Ok, so then should we bump to 5.3 ? This is one of the 2 remaining issues for 5.2. |
|
Bumping to 5.3 so we can think more about this. |
|
This PR have conflicts now. :-( |
|
@takluyver, thoughts about this one ? |
|
I don't think anyone wants it. I wrote it attempting to address a need @jdemeyer brought up, but it apparently makes things worse for him, not better. I don't think we can just set a Python signal handler and leave it, because a Python signal handler won't break out of compiled code which the user may have called. Jeroen has implemented the machinery in Cysignals to restore OS-level signal handlers from Python, but we don't want a compiled dependency in IPython. And there doesn't seem to be much interest in getting that functionality into the Python Closing this for now, anyway. |
|
In any case, I feel like this is mainly a |
3 participants
Closes gh-9944
This sets signal handlers for SIGTERM and SIGHUP while the prompt_toolkit prompt is active, letting it clean up the terminal before the process exits. When the prompt is not active, we restore the previous signals.
This can't work (as far as I know) if other code has set signal handlers at the C level. I don't think this is likely to come up often, but there's a new config option catch_signals=False which users can set to disable our manipulation of signal handlers.