Author hniksic
Recipients bquinlan, hniksic, pitrou
Date 2019-05-06.19:53:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1557172394.81.0.964820525741.issue36780@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2019-05-06 19:53:14hniksicsetrecipients: + hniksic, bquinlan, pitrou
2019-05-06 19:53:14hniksicsetmessageid: <1557172394.81.0.964820525741.issue36780@roundup.psfhosted.org>
2019-05-06 19:53:14hniksiclinkissue36780 messages
2019-05-06 19:53:14hniksiccreate