@vstinner Could you please take a look?

@AA-Turner sorry, misclick.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!

@ZeroIntensity If I get you right (feel free to correct me):

1. _PyThreadState_Attach is not signal-safe. If we call _PyThreadState_Attach from within faulthandler_user then another signal can call faulthandler_user again and this led to undefined state. IIUC, we can handle this with the reentrant flag, as faulthandler_dump_traceback did.
2. _PyEval_StopTheWorld is not signal-safe too. If we already in the stop-the-world state then calling _PyEval_StopTheWorld again will lead to deadlock on stoptheworld_mutex. And we can't handle this without changing the semantics of _PyEval_StopTheWorld. I don't intend to do this.

Therefore, if we want to safely handle non-fatal signals, then using the signal module seems like the only option. Or leave them as-is.

IIUC, we can handle this with the reentrant flag, as faulthandler_dump_traceback did.

Nope, because _PyThreadState_Attach will also try to acquire locks, leading to a deadlock if they're called under a signal.

I think it would be best to just document that faulthandler sometimes crashes if you mess with it.

We can't acquire the GIL or make a stop-the-world pause inside signal handlers, because they're not signal safe.

I agree. This approach is not safe at all. I suggest closing this PR.

@ZeroIntensity @vstinner Thanks!