[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2020-03-18 Thread STINNER Victor
STINNER Victor added the comment: I suggest to close this issue, I don't think that it can be implemented because of daemon threads. -- > This behavior should instead be triggered by the thread's interpreter > finalizing rather than the runtime. What is the motivation for that? -- take_g

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-05-09 Thread STINNER Victor
STINNER Victor added the comment: IMHO PR 12679 change should wait until Py_EndInterpreter() is reworked to better cleanup its state and its threads. -- ___ Python tracker __

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-05-08 Thread Nick Coghlan
Nick Coghlan added the comment: Another potential issue here is if a thread belonging to another interpreter attempts to access the interpreter being cleaned up. -- ___ Python tracker __

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-05-08 Thread Nick Coghlan
Nick Coghlan added the comment: Pablo pointed out a problem with this change at the PyCon sprints: the thread cleanup code doesn't currently distinguish between "Python created daemon thread" and "thread created by the embedding application". That's already somewhat problematic if an embeddi

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-04-29 Thread STINNER Victor
Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-04-03 Thread Joannah Nanjekye
Change by Joannah Nanjekye : -- keywords: +patch pull_requests: +12606 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

2019-03-29 Thread Eric Snow
New submission from Eric Snow : Currently when a thread acquires the GIL, it subsequently exits if the runtime is finalizing. This helps with some cases like with stopping daemon threads. This behavior should instead be triggered by the thread's interpreter finalizing rather than the runtime