instead of raising InterruptedError if the connection is interrupted by
signals, signal handlers don't raise an exception and the socket is blocking or
has a timeout.
socket.socket.connect() still raise InterruptedError for non-blocking sockets.
to its signal handlers.
Use also _Py_write_noraise() instead of write() to retry write() if it is
interrupted by a signal (fail with EINTR).
faulthandler.dump_traceback() also calls PyErr_CheckSignals() to call the
Python signal handler if a signal was received.
Fixed ambigious reverse mappings. Added many new mappings. Import mapping
is no longer applied to modules already mapped with full name mapping.
Added tests for compatible pickling and unpickling and for consistency of
_compat_pickle mappings.
Fixed ambigious reverse mappings. Added many new mappings. Import mapping
is no longer applied to modules already mapped with full name mapping.
Added tests for compatible pickling and unpickling and for consistency of
_compat_pickle mappings.
timeout when interrupted by a signal, except if the signal handler raises an
exception. This change is part of the PEP 475.
The asyncore and selectors module doesn't catch the InterruptedError exception
anymore when calling select.select(), since this function should not raise
InterruptedError anymore.
This mimics get_param's error handling for the most part. It is slightly
better in some regards as get_param can produce some really weird results for
duplicate *0* parts. It departs from get_param slightly in that if we have a
mix of non-extended and extended pieces for the same parameter name, the new
parser assumes they were all supposed to be extended and concatenates all the
values, whereas get_param always picks the non-extended parameter value. All
of this error recovery is pretty much arbitrary decisions...
Previously, if you hit ctl-c while the pager was active, the python that
launched the subprocess for the pager would see the KeyboardInterrupt in the
__exit__ method of the subprocess context manager where it was waiting for the
subprocess to complete, ending the wait. This would leave the pager running,
while the interactive interpreter, after handling the exception by printing
it, would go back to trying to post a prompt...but the pager would generally
have the terminal in raw mode, and in any case would be still trying to read
from stdin. On some systems, even exiting python at that point would not
restore the terminal mode. The problem with raw mode could also happen if
ctl-C was hit when pydoc was called from the shell command line and the pager
was active.
Instead, we now wait on the subprocess in a loop, ignoring KeyboardInterrupt
just like the pager does, until the pager actually exits.
(Note: this was a regression relative to python2...in python2 the pager
is called via system, and system does not return until the pager exits.)
Issue #23654: Turn off ICC's tail call optimization for the stack_overflow
generator. ICC turns the recursive tail call into a loop.
Patch written by Matt Frank.
