[issue14073] allow per-thread atexit()

Change by STINNER Victor : -- components: +Subinterpreters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14073] allow per-thread atexit()

Change by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14073] allow per-thread atexit()

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14073] allow per-thread atexit()

Vadim Markovtsev added the comment: I agree that there must be some way to join the threads before exiting, with a callback or anything else. Currently, my thread pool implementation has to monkey patch sys.exit and register SIGINT handler to shutdown itself and avoid the hangup (100+ LoC to

[issue14073] allow per-thread atexit()

Mark Lawrence added the comment: The changes referenced in msg204494 ref: #19466 were reverted via changesets 9ce58a73b6b5 and 1166b3321012 -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073

[issue14073] allow per-thread atexit()

STINNER Victor added the comment: See also the issue #19466: the behaviour of daemon threads changed at Python exit in Python 3.4. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073

[issue14073] allow per-thread atexit()

Glenn Maynard added the comment: This would be useful. It shouldn't be part of atexit, since atexit.register() from a thread should register a process-exit handler; instead, something like threading.(un)register_atexit(). If called in a thread, the calls happen when run() returns; if called

[issue14073] allow per-thread atexit()

Christian Heimes added the comment: A couple of years ago I suggested something similar. I'd like to see both thread_start and thread_stop hooks so code can track the creation and destruction of threads. It's a useful feature for e.g. PyLucene or profilers. The callback must be inside the

[issue14073] allow per-thread atexit()

Antoine Pitrou added the comment: Most logical would be an API on Thread objects (this would obviously only work with threading-created threads). A PEP also sounds unnecessary for a single new API. -- nosy: +tim.peters ___ Python tracker

[issue14073] allow per-thread atexit()

Tarek Ziadé ziade.ta...@gmail.com added the comment: @grahamd : sometimes you don't own the code that contains the thread, so I think it's better to be able to shutdown properly all flavors of threads. -- ___ Python tracker rep...@bugs.python.org

[issue14073] allow per-thread atexit()

Graham Dumpleton graham.dumple...@gmail.com added the comment: Reality is that the way Python behaviour is defined/implemented means that it will wait for non daemonised threads to complete before exiting. Sounds like the original code is wrong in not setting it to be daemonised in the first

[issue14073] allow per-thread atexit()

Tarek Ziadé ziade.ta...@gmail.com added the comment: Is there any good reason not to add this feature ? what would be the problem ? It does seem to be for the best, I don't see any drawbacks -- ___ Python tracker rep...@bugs.python.org

[issue14073] allow per-thread atexit()

Graham Dumpleton graham.dumple...@gmail.com added the comment: At the moment you have showed some code which is causing you problems and a vague idea. Until you show how that idea may work in practice it is a bit hard to judge whether what it does and how it does it is reasonable. --

[issue14073] allow per-thread atexit()

Tarek Ziadé ziade.ta...@gmail.com added the comment: Mmm.. you did not say yet why you are against this feature, other than the lib *should not* use non-daemonized threads This sounds like the lib should not use feature X in Python because it will block everything And now we're proposing to

[issue14073] allow per-thread atexit()

Graham Dumpleton graham.dumple...@gmail.com added the comment: I haven't said I am against it. All I have done so far is explain on the WEB-SIG how mod_wsgi works and how Python currently works and how one would normally handle this situation by having the thread be daemonised. As for the

[issue14073] allow per-thread atexit()

Tarek Ziadé ziade.ta...@gmail.com added the comment: Add an actual example here at least of how with the proposed feature your code would then look. That's the part I am not sure at all about in fact. I don't know at all the internals in the shutdown process in Python and I was hoping

[issue14073] allow per-thread atexit()

Graham Dumpleton graham.dumple...@gmail.com added the comment: Except that calling it at the time of current atexit callbacks wouldn't change the current behaviour. As quoted in WEB-SIG emails the sequence is: wait_for_thread_shutdown(); /* The interpreter is still entirely intact at

[issue14073] allow per-thread atexit()

Changes by Zvezdan Petkovic zvez...@computer.org: -- nosy: +zvezdan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073 ___ ___ Python-bugs-list

[issue14073] allow per-thread atexit()

New submission from Tarek Ziadé ziade.ta...@gmail.com: If you try to run the code below and stop it with ctrl+C, it will lock because atexit is never reached. Antoine proposed to add a way to have one atexit() per thread, so we can call some cleanup code when the app shuts down and there are

[issue14073] allow per-thread atexit()

Changes by Tarek Ziadé ziade.ta...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073 ___ ___ Python-bugs-list

[issue14073] allow per-thread atexit()

Changes by Antoine Pitrou pit...@free.fr: -- components: +Interpreter Core, Library (Lib) nosy: +neologix type: behavior - enhancement versions: -Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14073

[issue14073] allow per-thread atexit()

Graham Dumpleton graham.dumple...@gmail.com added the comment: My take on this is that if wanting to interact with a thread from an atexit callback, you are supposed to call setDaemon(True) on the thread. This is to ensure that on interpreter shutdown it doesn't try and wait on the thread