➜
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.
Created on 2017-03-31 16:35 by s3rvac, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Messages (3) | |||
|---|---|---|---|
| msg290923 - (view) | Author: Petr Zemek (s3rvac) | Date: 2017-03-31 16:35 | |
multiprocessing.Pool.__exit__() calls terminate() instead of close(). Why? Wouldn't it be better (and more expected from a user's point of view) if it called close()? Reasons: - Calling close() would wait until all tasks are completed before shutting down the pool instead of terminating them abruptly when some of them may still be running. - concurrent.futures.ProcessPoolExecutor.__exit__() calls shutdown(wait=True), which waits until all tasks are finished. In this regard, the behavior of Pool.__exit__() is inconsistent. See also this comment by Dan O'Reilly (http://bugs.python.org/msg242120), who expressed an identical concern two years ago. |
|||
| msg290951 - (view) | Author: Josh Rosenberg (josh.r) *  |
Date: 2017-04-01 01:05 | |
I suspect it's far too late to change this, given compatibility constraints. If you want it to close instead of terminate, contextlib.closing is always an option. |
|||
| msg290972 - (view) | Author: Antoine Pitrou (pitrou) *  |
Date: 2017-04-01 09:19 | |
I agree it's far too late. Multiple existing libraries may rely on the current behaviour. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:44 | admin | set | github: 74140 |
| 2017-04-01 09:19:52 | pitrou | set | status: open -> closed nosy: + pitrou messages: + msg290972 resolution: wont fix stage: resolved |
| 2017-04-01 01:05:57 | josh.r | set | nosy:
+ josh.r messages: + msg290951 |
| 2017-03-31 16:45:11 | xiang.zhang | set | nosy:
+ davin |
| 2017-03-31 16:35:59 | s3rvac | create | |