Pablo Galindo Salgado <pablog...@gmail.com> added the comment:
> 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38501> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
