[docs] [issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor <vstinner at redhat.com> added the comment:

I reverted the change in 2.7, 3.6, 3.7 and master branches because it introduces a regression and we are very close to a release:
https://mail.python.org/pipermail/python-dev/2018-December/155920.html

I don't want to have the pressure to push a quick fix. I would like to make sure that we have enough time to design a proper fix. I'm not saying that Pablo's fix is not correct, it's just bad timing.

This bug is likely here for a long time, so I think that it's ok to still have it in the next 3.6 and 3.7 bugfix releases.

I suggest to open a discussion on the python-dev mailing list about multiprocessing relying on the garbage collector and lifetime of multiprocessing objects (Pool, Process, result, etc.). It seems like I disagree with Pablo and tzickel, whereas Armin Rigo (PyPy which has a different GC) is more on my side (release explicitly resources) :-) I would prefer to move towards explicit resource managment instead of relying on destructors and the garbage collector. For example, it's a bad practice to rely on these when using PyPy.

See my previous comments about issues related to multiprocessing objects lifetime.

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34172>
_______________________________________