GeezerVison

This looks like the correct fix to me. A few comments:

• description on the PR doesn't match the implementation
• in the news file "now stays alive until it returns" also applies to GIL-enabled build, suggest rewording to be clearer
• related bug, can be a separate issue: PyErr_SetInterruptEx is documented to not need attached threadstate but compare_handler() looks at func. QSBR doesn't protect detached threads.

One other case is getsignal() from a subinterpreter: it currently returns the main interpreter’s handler object, but the delayed decref only waits for readers in the main interpreter.

Would it make sense to move the Python handler table into per-interpreter state? Python signal handlers can currently only be installed and run in the main interpreter, so we’d need to decide what getsignal() should do in a subinterpreter. Not sure if the current racy behavior is intended -- probably not! The C signal state would still need to be process-wide, but avoiding shared Python handler objects would make their lifetime easier to manage.

Another approach would be to use a mutex, rather than QSBR. In general it's good to avoid putting more things in the QSBR queue. Also, since the hander is size zero, it doesn't advance the QSBR sequence. This is not on a hot path and so the extra cost of a mutex (which is quite small anyhow) should not be significant. One complication with a mutex, we need to reset it after forking, like the import lock.

A third option would be to use tryincref. That gives prompt de-allocation and nothing to do after fork. Neither the mutex or tryincref fixes the PyErr_SetInterruptEx problem, unfortunately.

Edit: comparison of different options:

Actually, we don't need the reset after fork, just need to be careful not to be holding the mutex when fork happens. The decref of the old handler must be outside the critical section since a destructor could call fork(). Order would be for writer:

1. Lock.
2. Exchange the slot pointer (no decref, no Python code).
3. Unlock.
4. Decref the old handler; any destructor, including one that forks, runs here with no lock held

For reader: lock, load, incref, unlock, then call the handler. An incref never runs arbitrary code, so nothing inside either locked region can fork, detach or re-enter. I think I prefer the mutex approach.