@@ -401,7 +401,11 @@ Initializing and finalizing the interpreter
401
401
freed. Some memory allocated by extension modules may not be freed. Some
402
402
extensions may not work properly if their initialization routine is called more
403
403
than once; this can happen if an application calls :c:func:`Py_Initialize` and
404
- :c:func: `Py_FinalizeEx ` more than once.
404
+ :c:func: `Py_FinalizeEx ` more than once. :c:func: `Py_FinalizeEx ` must not be
405
+ called recursively from within itself. Therefore, it must not be called by any
406
+ code that may be run as part of the interpreter shutdown process, such as
407
+ :py:mod: `atexit ` handlers, object finalizers, or any code that may be run while
408
+ flushing the stdout and stderr files.
405
409
406
410
.. audit-event :: cpython._PySys_ClearAuditHooks "" c.Py_FinalizeEx
407
411
@@ -804,6 +808,29 @@ thread, where the CPython global runtime was originally initialized.
804
808
The only exception is if :c:func:`exec` will be called immediately
805
809
after.
806
810
811
+ .. _cautions-regarding-runtime-finalization:
812
+
813
+ Cautions regarding runtime finalization
814
+ ---------------------------------------
815
+
816
+ In the late stage of :term:`interpreter shutdown`, after attempting to wait for
817
+ non-daemon threads to exit (though this can be interrupted by
818
+ :class:`KeyboardInterrupt`) and running the :mod:`atexit` functions, the runtime
819
+ is marked as *finalizing*: :c:func:`_Py_IsFinalizing` and
820
+ :func:`sys.is_finalizing` return true. At this point, only the *finalization
821
+ thread* that initiated finalization (typically the main thread) is allowed to
822
+ acquire the :term:`GIL`.
823
+
824
+ If any thread, other than the finalization thread, attempts to acquire the GIL
825
+ during finalization, either explicitly via :c:func:`PyGILState_Ensure`,
826
+ :c:macro:`Py_END_ALLOW_THREADS`, :c:func:`PyEval_AcquireThread`, or
827
+ :c:func:`PyEval_AcquireLock`, or implicitly when the interpreter attempts to
828
+ reacquire it after having yielded it, the thread enters a permanently blocked
829
+ state where it remains until the program exits. In most cases this is harmless,
830
+ but this can result in deadlock if a later stage of finalization attempts to
831
+ acquire a lock owned by the blocked thread, or otherwise waits on the blocked
832
+ thread.
833
+
807
834
808
835
High-level API
809
836
--------------
@@ -847,11 +874,14 @@ code, or when embedding the Python interpreter:
847
874
ensues.
848
875
849
876
.. note::
850
- Calling this function from a thread when the runtime is finalizing
851
- will terminate the thread, even if the thread was not created by Python.
852
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
853
- check if the interpreter is in process of being finalized before calling
854
- this function to avoid unwanted termination.
877
+ Calling this function from a thread when the runtime is finalizing will
878
+ hang the thread until the program exits, even if the thread was not
879
+ created by Python. Refer to
880
+ :ref:`cautions-regarding-runtime-finalization` for more details.
881
+
882
+ .. versionchanged:: 3.12
883
+ Hangs the current thread, rather than terminating it, if called while the
884
+ interpreter is finalizing.
855
885
856
886
.. c:function:: PyThreadState* PyThreadState_Get()
857
887
@@ -893,11 +923,14 @@ with sub-interpreters:
893
923
to call arbitrary Python code. Failure is a fatal error.
894
924
895
925
.. note::
896
- Calling this function from a thread when the runtime is finalizing
897
- will terminate the thread, even if the thread was not created by Python.
898
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
899
- check if the interpreter is in process of being finalized before calling
900
- this function to avoid unwanted termination.
926
+ Calling this function from a thread when the runtime is finalizing will
927
+ hang the thread until the program exits, even if the thread was not
928
+ created by Python. Refer to
929
+ :ref:`cautions-regarding-runtime-finalization` for more details.
930
+
931
+ .. versionchanged:: 3.12
932
+ Hangs the current thread, rather than terminating it, if called while the
933
+ interpreter is finalizing.
901
934
902
935
.. c:function:: void PyGILState_Release(PyGILState_STATE)
903
936
@@ -1175,17 +1208,20 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
1175
1208
If this thread already has the lock, deadlock ensues.
1176
1209
1177
1210
.. note::
1178
- Calling this function from a thread when the runtime is finalizing
1179
- will terminate the thread, even if the thread was not created by Python.
1180
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
1181
- check if the interpreter is in process of being finalized before calling
1182
- this function to avoid unwanted termination.
1211
+ Calling this function from a thread when the runtime is finalizing will
1212
+ hang the thread until the program exits, even if the thread was not
1213
+ created by Python. Refer to
1214
+ :ref:`cautions-regarding-runtime-finalization` for more details.
1183
1215
1184
1216
.. versionchanged:: 3.8
1185
1217
Updated to be consistent with :c:func:`PyEval_RestoreThread`,
1186
1218
:c:func:`Py_END_ALLOW_THREADS`, and :c:func:`PyGILState_Ensure`,
1187
1219
and terminate the current thread if called while the interpreter is finalizing.
1188
1220
1221
+ .. versionchanged:: 3.12
1222
+ Hangs the current thread, rather than terminating it, if called while the
1223
+ interpreter is finalizing.
1224
+
1189
1225
:c:func:`PyEval_RestoreThread` is a higher-level function which is always
1190
1226
available (even when threads have not been initialized).
1191
1227
0 commit comments