Message341630
I agree with the last comment. The disowning functionality is only used in specific circumstances, so it's perfectly fine to keep the functionality as a shutdown flag. I also agree that the change cannot be *unconditional*, for backward compatibility if not for other reasons.
The StackOverflow question, and more importantly the existence of shutdown(wait=False), suggest that there are legitimate cases when one doesn't want to wait for all running futures to finish. If a flag to shutdown() is considered to complicate the API, then perhaps we could add an opt-out by subclassing the executor and overriding a semi-private method.
Currently there seems to be no way to just abandon the thread pool. Since user threads don't and never will support cancellation, the options are:
1. add the disown option to shutdown, as suggested
2. monkey-patch concurrent.futures to not block at shutdown
3. make functions executed by the pool externally cancellable
4. roll our own thread pool
#1 is suggested by this issue, and #2 is what we do now, but it's obviously unacceptable in the long term.
#3 is infeasible because the functions we submit to the pool heavily rely on http (through "requests") and database communication, which don't support user-driven cancellation.
#4 would be technically possible, but it would require reimplementing half of concurrent.futures (badly), just for the purpose of being able to get rid of the mandatory wait at interpreter exit. |
|
Date |
User |
Action |
Args |
2019-05-06 19:53:14 | hniksic | set | recipients:
+ hniksic, bquinlan, pitrou |
2019-05-06 19:53:14 | hniksic | set | messageid: <1557172394.81.0.964820525741.issue36780@roundup.psfhosted.org> |
2019-05-06 19:53:14 | hniksic | link | issue36780 messages |
2019-05-06 19:53:14 | hniksic | create | |
|