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 pablogsal
Recipients Andrew Nelson, Paul Silisteanu, cjrh, larsoner, pablogsal, ralf.gommers, stefanor
Date 2020-04-10.18:53:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> One potential reason would be that the consequences of bad resource management in this case are different than in the open() case, i.e., here the interpreter hangs -- or Travis runs for your repo (SciPy) get stuck with over-50-minute errors, which is how we started looking for how to track it down.

Agreed, but is the same problem: resources need to be managed. I am although ok if you want to add some targeted warning to the multiprocessing pool docs indicating what can happen if the resource is not properly managed.

> Indeed, my point is more about potential prevalence: this (now incorrect) problematic usage pattern was the first example in the docs for multiprocessing for a long time, indicating that there might be a lot of code in the wild that might (still) make use of it.

Right, we put great efforts to make the code such that even incorrect usages do not hang (and believe me, is *very* challenging) but we cannot sacrifice correct usage fixes or big improvements so incorrect usages keep working even if they are leaking resources. Hopefully, more and more people start using the context manager or are aware that are doing something wrong leaking the pool.


In conclusion, I agree that maybe adding some targetted warning to the pool docs about this is in place. When I prepare the PR, would you like to review the message to confirm that is clear enough and that makes sense?
Date User Action Args
2020-04-10 18:53:20pablogsalsetrecipients: + pablogsal, cjrh, stefanor, ralf.gommers, larsoner, Andrew Nelson, Paul Silisteanu
2020-04-10 18:53:20pablogsalsetmessageid: <>
2020-04-10 18:53:20pablogsallinkissue38501 messages
2020-04-10 18:53:20pablogsalcreate