Apply suggestions from code review

Co-authored-by: Petr Viktorin <encukou@gmail.com>

Author: ZeroIntensity

Doc/c-api/interp-lifecycle.rst

@@ -608,7 +608,8 @@ it possible to avoid these issues by temporarily preventing finalization:
 
 .. seealso::
 
-   :pep:`788`
+   :pep:`788` explains the design, motivation and rationale
+   for these APIs.
 
 .. c:type:: PyInterpreterGuard
 
@@ -624,14 +625,19 @@ it possible to avoid these issues by temporarily preventing finalization:
    guards for that interpreter. This means that if you forget to close an
    interpreter guard, the process will **permanently hang** during
    finalization!
-
+
+   Holding a guard for an interpreter is similar to holding a
+   :term:`strong reference` to a Python object, except finalization does not happen
+   automatically after all guards are released: it requires an explicit 
+   :c:func:`Py_EndInterpreter` call.
+
    .. versionadded:: next
 
 
 .. c:function:: PyInterpreterGuard *PyInterpreterGuard_FromCurrent(void)
 
    Create a finalization guard for the current interpreter. This will prevent
-   finalization from occuring until the guard is closed.
+   finalization until the guard is closed.
 
    For example:
 
@@ -764,8 +770,8 @@ deleted. This can be done using interpreter views.
    Failure indicates that the process is out of memory or that the main
    interpreter has finalized (or never existed).
 
-   Generally speaking, using this function is strongly discouraged, because
-   it typically compromises subinterpreter support for a program. It exists
+   Using this function in extension libraries is strongly discouraged, because
+   it typically compromises the library's subinterpreter support. It exists
    for exceptional cases where there is no other option (such as when a native
    threading library doesn't provide a ``void *arg`` parameter that could be
    used to store a ``PyInterpreterGuard`` or ``PyInterpreterView`` pointer).

Doc/c-api/threads.rst

@@ -545,9 +545,10 @@ will hang the process during interpreter finalization (see
    :c:func:`PyGILState_GetThisThreadState`. If the caller has no attached thread
    state or it otherwise doesn't match, then this returns ``0``.
 
-   .. note::
-      If the current Python process has ever created a subinterpreter, this
-      function will *always* return ``1``.
+   If the current Python process has ever created a subinterpreter, this
+   function will *always* return ``1``.
+
+   This is mainly a helper/diagnostic function.
 
    .. versionadded:: 3.4
 

Doc/whatsnew/3.15.rst

@@ -456,7 +456,7 @@ In the C API, :term:`interpreter finalization <interpreter shutdown>` can be
 problematic for many extensions, because :term:`attaching <attached thread
 state>` a thread state will permanently hang the thread, resulting in deadlocks
 and other spurious issues. Additionally, it has historically been impossible
-to atomically check whether an interpreter is alive, leading to crashes
+to safely check whether an interpreter is alive before using it, leading to crashes
 when a thread concurrently deletes an interpreter while another thread is
 trying to attach to it.