A PR adding a `Py_SetThreadExitCallback(func)` API guaranteeing the callback is called before `pthread_exit()` would allow anyone wanting to deal with their deadlocks to register `abort()` or `while(1) pause();` as their exit callback.  I'd be okay with that.  Anyone care to make a PR for that?

What should it do when SetThreadExitCallback has already been called?  Is that an error?  Are the callbacks chained?  In which order?  If someone passes nullptr does that undo it (please no!).  It is process global state that many things could wind up having an opinion on each with their own reason to require theirs to be the only one.  I vote for returning an error if a callback has already been set.  And not allowing unsetting a callback.

What we'd do internally at work is always guarantee our codebase's early application startup code (because we have such a thing) calls that to setup whichever exit callback we deem appropriate for everyone instead of today's default deadlock potential.

On pausing... agreed, it doesn't feel _comfortable_.  To me when faced with a known potential deadlock situation the only comfortable thing is to abort() as a process dying is always more useful than process hanging (or worse, partially hanging).

Sleeping on the problem, I don't really understand how `while(1) pause();` is significantly different than `pthread_exit()` when it comes to deadlocks, as it seems like an instantly terminated thread having state that needs cleanup should lead to a similar outcome as a thread with stuff needing cleanup that is now stuck in an infinite pause loop.  Neither of them is going to cleanup whatever (presumably a lock they hold) that leads something else to deadlock?  I guess the difference is that the thread stack  memory is at least not released back for potential reuse while other threads and pointers could still be referring to it when pausing as opposed to a pthread_exit?