New submission from Benjamin Fogle <benfo...@gmail.com>:
This is related to bpo-29988, and I'm happy to move this to there. I made this
a separate issue because this is a workaround, not a fix as was being discussed
there. Also unlike bpo-29988, this is not restricted to context managers or
finally blocks.
TL;DR: Raising exceptions from interrupt handlers (most notably
KeyboardInterrupt) can wreak havoc in ways that are impossible to fix. This
should be noted in the documentation, with a workaround.
I've attached a few example scripts that cause various strange behavior on
Linux when a KeyboardInterrupt is raised at just the right time. There are
likely many, many more possible examples:
- sigint_condition_1.py: Cause a deadlock with threading.Condition
- sigint_condition_2.py: Cause a double-release and/or notify on unacquired
threading.Condition
- sigint_tempfile.py: Cause NamedTemporaryFiles to not be deleted
- sigint_zipfile.py: Cause ZipExtFile to corrupt its state
When a user presses Ctrl+C, a KeyboardInterrupt will be raised on the main
thread at some later time. This exception may be raised after any bytecode, and
most Python code, including the standard library, is not designed to handle
exceptions that spring up from nowhere.
As a simple example, consider threading.Condition:
def __enter__(self):
return self._lock.__enter__()
The KeyboardInterrupt could be raised just prior to return. In this case,
__exit__ will never be called, and the underlying lock will remain acquired. A
similar problem occurs if KeyboardInterrupt occurs at the start of __exit__.
This can be mitigated by attempting to catch a KeyboardInterrupt *absolutely
everywhere*, but even then, it can't be fixed completely.
def __enter__(self):
try:
# it could happen here, in which case we should not unlock
ret = self._lock.__enter__()
# it could happen here, in which case we must unlock
except KeyboardInterrupt:
# it could, in theory, happen again right here
...
raise
return ret
# it could happen here, which is the same problem we had before
This is not restricted to context handlers or try/finally blocks. The zipfile
module is a good example of code that is almost certain to enter an
inconsistent state if a KeyboardInterrupt is raised while it's doing work:
class ZipExtFile:
...
def read1(self, n):
...
self._readbuffer = b''
# what happens if KeyboardInterrupt happens here?
self._offset = 0
...
Due to how widespread this is, it's not worth "fixing". (And honestly, it seems
to be a rare problem in practice.) I believe that it would be better to clearly
document that KeyboardInterrupt (or any exception propagated from a signal
handler) may leave the system
in an inconsistent state. Complex or high reliability applications should avoid
catching KeyboardInterrupt as a way of gracefully shutting down, and should
prefer registering their own SIGINT handler. They should also avoid raising
exceptions from signal handlers at all.
----------
assignee: docs@python
components: Documentation
messages: 380868
nosy: benfogle, docs@python
priority: normal
severity: normal
status: open
title: KeyboardInterrupt should come with a warning
type: enhancement
versions: Python 3.10
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42340>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
