Skip to content

Commit 6c1340a

Browse files
ZeroIntensityencukou
authored andcommitted
gh-144748: Document 3.12 and 3.14 changes to PyErr_CheckSignals (GH-144982)
(cherry picked from commit 0629261) Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: Petr Viktorin <encukou@gmail.com>
1 parent 635d1b7 commit 6c1340a

File tree

1 file changed

+35
-17
lines changed

1 file changed

+35
-17
lines changed

Doc/c-api/exceptions.rst

Lines changed: 35 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -673,28 +673,46 @@ Signal Handling
673673
single: SIGINT (C macro)
674674
single: KeyboardInterrupt (built-in exception)
675675
676-
This function interacts with Python's signal handling.
676+
Handle external interruptions, such as signals or activating a debugger,
677+
whose processing has been delayed until it is safe
678+
to run Python code and/or raise exceptions.
677679
678-
If the function is called from the main thread and under the main Python
679-
interpreter, it checks whether a signal has been sent to the processes
680-
and if so, invokes the corresponding signal handler. If the :mod:`signal`
681-
module is supported, this can invoke a signal handler written in Python.
680+
For example, pressing :kbd:`Ctrl-C` causes a terminal to send the
681+
:py:data:`signal.SIGINT` signal.
682+
This function executes the corresponding Python signal handler, which,
683+
by default, raises the :exc:`KeyboardInterrupt` exception.
682684
683-
The function attempts to handle all pending signals, and then returns ``0``.
684-
However, if a Python signal handler raises an exception, the error
685-
indicator is set and the function returns ``-1`` immediately (such that
686-
other pending signals may not have been handled yet: they will be on the
687-
next :c:func:`PyErr_CheckSignals()` invocation).
685+
:c:func:`!PyErr_CheckSignals` should be called by long-running C code
686+
frequently enough so that the response appears immediate to humans.
688687
689-
If the function is called from a non-main thread, or under a non-main
690-
Python interpreter, it does nothing and returns ``0``.
688+
Handlers invoked by this function currently include:
691689
692-
This function can be called by long-running C code that wants to
693-
be interruptible by user requests (such as by pressing Ctrl-C).
690+
- Signal handlers, including Python functions registered using
691+
the :mod:`signal` module.
694692
695-
.. note::
696-
The default Python signal handler for :c:macro:`!SIGINT` raises the
697-
:exc:`KeyboardInterrupt` exception.
693+
Signal handlers are only run in the main thread of the main interpreter.
694+
695+
(This is where the function got the name: originally, signals
696+
were the only way to interrupt the interpreter.)
697+
698+
- Running the garbage collector, if necessary.
699+
700+
- Executing a pending :ref:`remote debugger <remote-debugging>` script.
701+
702+
If any handler raises an exception, immediately return ``-1`` with that
703+
exception set.
704+
Any remaining interruptions are left to be processed on the next
705+
:c:func:`PyErr_CheckSignals()` invocation, if appropriate.
706+
707+
If all handlers finish successfully, or there are no handlers to run,
708+
return ``0``.
709+
710+
.. versionchanged:: 3.12
711+
This function may now invoke the garbage collector.
712+
713+
.. versionchanged:: 3.14
714+
This function may now execute a remote debugger script, if remote
715+
debugging is enabled.
698716
699717
700718
.. c:function:: void PyErr_SetInterrupt()

0 commit comments

Comments
 (0)