@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 phraseI 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 withinfaulthandler_user then another signal can callfaulthandler_user again and this led to undefined state. IIUC, we can handle this with thereentrant flag, asfaulthandler_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 onstoptheworld_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 thesignal 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.