The source tree contains dozens of loops of this form:

    int res;
    do {
        Py_BEGIN_ALLOW_THREADS
        res = some_system_call(arguments...);
        Py_END_ALLOW_THREADS
    } while (res < 0 && errno == EINTR && !PyErr_CheckSignals());

Now that it is possible to call PyErr_CheckSignals without holding the
GIL, the locking operations can be moved out of the loop:

    Py_BEGIN_ALLOW_THREADS
    do {
        res = some_system_call(arguments...);
    } while (res < 0 && errno == EINTR && !PyErr_CheckSignals());
    Py_END_ALLOW_THREADS

This demonstrates the motivation for making it possible to call
PyErr_CheckSignals without holding the GIL.  It shouldn’t make any
measurable difference performance-wise for _these_ loops, which almost
never actually cycle; but for loops that do cycle many times it’s very
much desirable to not take and release the GIL every time through.

In some cases I also moved uses of _Py_(BEGIN|END)_SUPPRESS_IPH, which
is often paired with Py_(BEGIN|END)_ALLOW_THREADS, to keep the pairing
intact.  It was already considered safe to call PyErr_CheckSignals
from both inside and outside an IPH suppression region.

More could be done in this vein: I didn’t change any loops where the
inside of the loop was more complicated than a single system call,
_except_ that I did refactor py_getentropy and py_getrandom (in
bootstrap_hash.c) to make it possible to move the unlock and lock
outside the loop, demonstrating a more complicated case.