Remove the term 'signal handler.'

Author: ZeroIntensity

peps/pep-0788.rst

@@ -337,7 +337,7 @@ that it always works. An approach that were to return a failure based on
 the start-time of the thread could cause spurious issues.
 
 In the case where it is useful to let the interpreter finalize, such as in
-a signal handler where there's no guarantee that the thread will start,
+an asynchronous callback where there's no guarantee that the thread will start,
 strong references to an interpreter can be acquired through
 :c:func:`PyInterpreterState_Lookup`.
 
@@ -409,7 +409,7 @@ A non-zero reference count prevents the interpreter from finalizing.
     Similar to :c:func:`PyInterpreterState_Hold`, but looks up an interpreter
     based on an ID (see :c:func:`PyInterpreterState_GetID`). This has the
     benefit of allowing the interpreter to finalize in cases where the thread
-    might not start, such as inside of a signal handler.
+    might not start, such as inside of an asynchronous callback.
 
     This function will return ``NULL`` without an exception set on failure.
     If the return value is non-``NULL``, then the returned interpreter will be
@@ -661,10 +661,10 @@ Asynchronous callback example
 *****************************
 
 As stated in the Motivation_, there are many cases where it's desirable
-to call Python in an asynchronous callback, such as a signal handler. In that
-case, it's not safe to call :c:func:`PyInterpreterState_Hold`, because it's
-not guaranteed that :c:func:`PyThreadState_Ensure` will ever be called, which
-would deadlock finalization.
+to call Python in an asynchronous callback. In that case, it's not safe to
+call :c:func:`PyInterpreterState_Hold`, because it's not guaranteed that
+:c:func:`PyThreadState_Ensure` will ever be called, which would deadlock
+finalization.
 
 This scenario requires :c:func:`PyInterpreterState_Lookup`, which only prevents
 finalization when the lookup has been made.