This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Windson Yang, benjamin.peterson, davin, docs@python, mattip, ned.deily, pablogsal, pitrou, tzickel, vstinner, zach.ware
Date 2018-12-06.09:42:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544089324.47.0.788709270274.issue34172@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-12-06 09:42:04vstinnersetrecipients: + vstinner, pitrou, benjamin.peterson, ned.deily, docs@python, zach.ware, mattip, davin, tzickel, pablogsal, Windson Yang
2018-12-06 09:42:04vstinnersetmessageid: <1544089324.47.0.788709270274.issue34172@psf.upfronthosting.co.za>
2018-12-06 09:42:04vstinnerlinkissue34172 messages
2018-12-06 09:42:04vstinnercreate