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-03.22:29:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> A. The documentation explicitly says: "When the pool object is garbage collected terminate() will be called immediately." (Happened till a code refactor 9 years ago introduced this bug).

It is a *very bad* practice to rely on __del__. Don't do that. That's why we introduced ResourceWarning.

> (Till the end of the file almost)

Is this API *incompatible* with pool.close()? Explicitly release resources?

> Víctor, I have a PR fixing this in: (...) The fix is really simple, so I think we should fix it and not revert the change on this case.

I'm not comfortable with the fix. I cannot explain why but I feel like adding a strong dependency from a child to its parent is going to lead to more bugs, not less. It sounds like a recipe for reference cycles. Maybe I'm just plain wrong.

At this point, I would like that someone explains me what the problem is. is a solution, ok, but what is the problem? What does the code hangs, whereas previously it was fine? Is the example code really correct? Do we want to support such usage?

I understand that msg330864 rely on black magic to expect that it's going to be fine. The lifetime of the pool is implicit and it sounds like a bad design. I don't want to endorse that.
Date User Action Args
2018-12-03 22:29:53vstinnersetrecipients: + vstinner, pitrou, benjamin.peterson, ned.deily, docs@python, zach.ware, mattip, davin, tzickel, pablogsal, Windson Yang
2018-12-03 22:29:53vstinnersetmessageid: <>
2018-12-03 22:29:53vstinnerlinkissue34172 messages
2018-12-03 22:29:53vstinnercreate