Gregory P. Smith <g...@krypto.org> added the comment:

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?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42969>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to